W3C Meeting (2001-2-28)

Disclaimer: These notes are a rough, personal account of what took place at the meeting. They are provided for the use of those who were not able to attend but are not meant to be a full or completely accurate account of the proceedings. Many portions of the meeting are not documented or may be misconstrued. All text within is a rough paraphrasing except where in quotes (""). Corrections and additions are appreciated.

TimBL: Axioms, Architecture and Aspirations

(Slides are available, these notes are just non-slide things.)

Just one person among many in enthusiasm. Doing some thinking about what a URI identifies. Setting up a URI trust so that W3C and others can have URIs live on.

Adding a new URI scheme is very expensive -- "shakes the root of the whole tree" because every program needs to learn about it. WebDAV did this, it was bad.

Lots of other schemes -- don't have to use HTTP. Look at the right spec to find out what the URI means, the content means, the fragment ID means. Well-known bug: fragment ID syntax is different in each spec. Important that alphanumeric strings work across everything. Reason for XPointer "raw name" syntax.

New block diagram. Many of the things have moved on through the process.

New Semantic Web diagram. The "anybody can say anything about anybody" rule makes things Web-like. Diagram is changing. Block diagrams made in Adobe Illustrator*. Working on a new one: uri/unicode*; xml/namespace; xml schema; rdf m&s; rdf schema; ontology; rules; logic; proof; signatures (going all the way down); trust. Ontology people ignore etymology of the word and let you say whether things are disjoint so system can conclude that "Jack is not a car". I pray that logicians don't have us going around in circles forever. Most of the stuff out there is already done by the time we get there. World tied together that if two systems use different ways they still can exchange proofs which can easily be validated. Power of logic* + Public Key Crypto*. Systems are "hopelessly poor" only letting you divide world into trusted, untrusted and sort-of trusted. Web of trust lets us represent "what happens in society". Always difficult, have to sacrifice some of reality to make one of these diagrams.

When you talk voice, you don't have the big screen. The Web relies on the Windows interface of shared pixels with state. On a phone, the state is in your head. Forms becoming more conversation. Semantic instant mesaging with conversation. Remote operations with XML protocols. Look at documents as fratic of conversations.

conversation is not self-describing -- only individual pieces.

lots of environments for documents to find themselves. document doesn't know who the reader is. has a namespace pointer to a "namespace". Message is a little different, has a to pointer and a from pointer and a namespace pointer. you can write a promise in a message, and it has unchanging date. things said never change. transaction is two messages, response and request with a possible connection. Protocol is two documents with the same protocol namespace. service is an abstract protocol. HTTP forgot requirement about social request that an HTTP request is an assertion and has real-life meaning. We get hung up on strcutrure and forget what things mean. Things called "binding" lets you know that things will happen in a service.

Questions where to do things -- at which layer to encrypt. All of them! just as long as you don't compress thingds that are encrypted. Means you can uncouple things. take layers with a grain of salt.

Questions

Enough independent consortia already! WG don't need to be independent. Remember: KISS. [claps, including from Tim] I got extremely confused with Ontology and rules. AI people have made a good living by confusing people. the consortium needs to simplify rules and ontologies so that a grandmother can use them. Response from Tim: I applaude KISS, when you make a standard you add the features you need but shrivel down what everyone can agree. but you still have cruft. i have some in URIs and XML. but how do we do it socially? how do we clean up?

WG Chairs need process tools to do post-recommendation analysis, clean-up. Response: That's a good idea. How many people would feel that cleanup is reasonable? Yeah, have to be aware of second-system.

Graham Klyne*: Making proofs something a grandmother can understand is no more important having a grandmother change an engine in her car. Tim: is a system with two axioms from which all of mathematics can be derived simple or complicated?

in any social organization there are pressures agains doing a good job -- look at XML schema datatypes. W3C isn't immune. Process is the desk chairs on the Titanic. (Misha Wolf from Reuters) Tim: WG meeting is where these tensions arise. Needs to come out because 150 million televisions need it in ROM but something very very broken to be fixed!

Impressed with oversight (WAI*, I18N*). reasons for going to a website: good content, usability. No usability in W3C. Need a usability oversight comittee to assure that the user is addressed. Tim: Let's try and figure this out and get a proposal.

It's important that everyone knows only a small portion. We need use cases, formalisms, things that make it clear. WGs should not go forward unless things are clear. Requirement that there are clear statements of activity. We want people to send use cases so we can make sure that things work.

It takes my students only 10 seconds to understand angle brackets but ten years to understand the whole thing. Problems: People expect there should be something at a namespace. little common principle across everything. Too many exceptions! Need more coordination between groups like this meeting. Tim: We're starting a technical architecture group.

KISS is nice model but simplicity is in the eye of the beholder. When cars were simpler we had chokes -- but now interface is simpler. Simplicity of design is different than simplicity of use.

Web Architecture Panel

Janet Daly: Trying to find what's bleeding and getting the bleeding to stop.

???: Architecture is the underlying principles of Web components so that they work together. URIs and XML are examples. We need understandability of Recommendations. We should worry about how to plan in path to 2.0. No Architectural choke points, like a single registry. Trying to avoid talking about the process -- there's a developing proposal for a Technical Architecture group. Like a WG, but not. Uses the process.

???: We need to know where architecture is needed and where it is a waste. Something that a single WG cannot do by itself. Example: Hypertext group to figure out how Style works across namespaces.

???: Will just semantics be as powerful as we need? Transformations seem to be happening mostly server-side. Does this introduce device bias? Do I have to use an intermediary for processing? New languages need semantics for WCAG. Developing XML accessibility. What about usability?

???: One theme is WGs working together. How do the pieces go together? Tim has one idea. When I give talks: XML Query gets 20 people, how does XML work together? gets 200. We need to get things working together. WG will get things wrong if they don't work with other groups. How will you write the testimonial? How will your company relate?

????: Let's get rid of the bleeding metaphor. We are trying to create new technologies. a natural growing process. I see TAG has having a role where it can resolve points of dispute/interaction between techs. also has to make the overall picture. We're going to see more and more URI relationships. We cannot embed XML documents inside XML documents. This is a problem.

Eric Miller: The goal of the SW is to describe and link for automation, integration and re-use. Building standards, technologies, applications. The Semantic Web simply layers semantics over links. Instead of "I point to Microsft" or "I point to this document" it becomes "I work for Microsoft" or "I wrote this document". We use URIs with human and machine information to declare these link semantics. We use namespaces to package semantic modules to keep different meaning separate but also to package and modularize the semantics. Interpretation of namespaces.

Martin Duerst*: Relations between URIs and Unicode(?). Issues of normalization. Is this really needed? Could it be a bit simpler?

Comments from the Audience

If you don't have usability, you got problems. It's coming late but it needs to be part of the Architecture.

Graham Klyne*: What is the relationship between a URI and a resource? Tim thinks it's one-to-one. I can see it either way, but we need to align the assumptions.

Henry Thompson*, XML Schema: If this group is a fire-fighting group, it would be unfortunate. I hope that there's the time and vision for something more forward looking. Now that we have the XML Infoset, let's look at all these things with Infoset processing spanning all the infoset technology, but we need a shell script language for configuring processing. Someplace to stand to talk about the whole process -- something specifically cross-group. Can you do that? Response: TAG will be determined by who you vote to put on it.

David Orchard* of Jamcracker*: When we realize work is factored incorrectly (like XInclude) it's hard to fix the charter. Can we change charters? I second Henry's proposal. We need to worry about states in XML processing.

???: In XML 1.0 you couldn't embed on document in another, but now the W3C has fixed that. Namespaces solve the naming problem. The XML declaration and DOCTYPE declaration are no longer needed. XML schemas remove the need for DTDs. This problem is solved -- don't keep talking on it. You're looking at the old world. Response: I may not have the choice of whether I have a DTD or not. There's nothing I can do about that.

???: If you put 10 WG members in a room there are 11 opinions on what a namespace is. One said that I don't think the namespace problem will be solved in my lifetime. I'm ten years younger but I wonder whether it will be solved in my lifetime.

???: I want to say a word we've been talking around: Modularity. We have boundaries in the Web and distinctions so that we can have mutliple solutions, migrations and improvements without breaking things. But it requires discipline for all of us. We can't have leakage across boundaries. Leakage between way we address things and why we address. We get enormous power here. We need to resist temptation to have support for a specific vocabulary (semantics) in things like the DOM. I'd like to underline the processing model. This is a general issue. Syntactic structure is not always the best API. learn to live with these distinctions. narrow your scope so that there's no leaking.

???: I work with SQLX. As broad as W3C is, it needs to fit into a context. I know how XML and SQL need to fit. The TAG should consider how W3C fits into the rest of the world and can cooperate with the other pieces of the world. Response: XML Protocol has it in the charter that we need to work with the large outside world. Unlike most other WGs, we're on a public mailing list. We also have WG liaisons with other bodies.

???: When we draw boxes we see things in many settings. I read a book* by a guy named Alexander* and he talked about composibility and settings for real-life architecture.

Bob Schloss*: When we started it was about data streams, content but more current work is going to be for application programmers (XML Query, XML Protocol, XSLT engines have extensions, RDF logic talks about pluggable interfaces). We've done some API (DOM) but should WGs describe/suggest normative APIs and IDLs? Should we test, provide reference code? Use cases can be in English or in psuedo code. Are APIs in our charter?

Concluding Comments

???: The UI-Tech-Taskforce is doing Style over namespaces and we recognize Henry's pipeline. We do need to define APIs -- its our job. But we do need to be careful.

???: And I am the one who said namespaces won't be solved in my life. What did I mean? A Uniform Namespace Architecutre today is not feasible since problems are just starting. Let's solve problems today. We should come up with a seven-layer model for Web architecture.

XML Schemas

???: Some XML Schemas are "within shouting distance" of being valid RDF.

James Clark*: "I'm going to say some not very nice things about Schema. I do hope that the members of the Schema WG won't take it personally. I know how hard it is do to standards, especially in a big WG. I know the WG members have laboured long and hard, and with the best possible intentions.

"However, I have to say that I think the XML Schema effort has been nothing short of a disaster. First of all it's taken far too long. As for the result, I have met very few people outside the Schema WG who actually like Schemas, and even quite a few of those in the Schema WG don't seem to like it much.

"Now Schema Part 2 is not too bad. It's a little bit over-complex and little bit crufty, but no more so than the average standard.

"Schema Part 1 on the other hand, is ludicrously over-complex. The spec is virtually incomprehensible. And it just not very well designed. Feature is piled upon feature, ad-hoc restriction is piled on ad-hoc restriction, with no orthogonality, no composability. It's hard to learn, hard to use, hard to implement.

"And yet for all this, it's expressive power is feeble. For example, it can't do something as basic as saying that you can either have attribute X or attribute Y, or that you can have either attribute X or child element Y.

"Some of you may know that I've recently developed an alternative Schema language. The cynical amongst you may be thinking that I'm saying all these nasty things about the W3C's schema language just because I've got a competitor Schema language. But that's actually backwards. I only started work on my Schema language, TREX, a couple of months ago when it became clear how W3C Schema's would end up. I created TREX because I found that W3C's XML Schema's was something I just not willing to live with. Also I think if one disagrees with a design not just in details, but fundamentally, the best away to give substance to that is to exhibit an alternative. I think TREX shows that a Schema language can be simple, can be easy to learn and use and yet be useful, indeed in some ways more functional than W3C Schemas." (quote is from notes James Clark* kindly provided to me)

Henry Thompson*: It's useful to have this discussion. The co-contraint/attribute problem is functionality we'd like to see and we're fast-tracking it for the next version. There was also a decision to not fix things now. It's waiting for "day 2" but it is coming. On the tradeoff between functionality and complexity: part of the problem is that one person's 80 is another person's 20 and they're both on the WG. I don't think it's a mistake. The difference is that XML Schema is about exploiting information in XML documents by augmenting the Infoset. It's the role other groups need schemas to play for them. Other specs just do validation so they have a simpler spec. There's no social problem here.

Response: Use the Primer or the Guide for the Rest of Us, it's not that bad.

Misha Wolf*: How did Date and Time get so bad? Some complaints on the connection between I18N and Schemas...

Phil Wadler*: TREX, MSL, etc. all add the power and make things simpler. It's unusual when there is an opportunity to do this, and we should all appreciate that opportunity is being missed here. You implied that one problem with the development is the work with all the other WGs. You said no to every single one of our suggestions from XML Query. [NB. This is a personal comment, not necessarily representing the view of the XML Query working group.] Michael Sperberg MacQueen*: That's an absolute falsehood! Not useful! Look at the public record. Phil Wadler*: I'm sorry, my statement was too strong. My feeling is that when we had something important, you said no. Others can look at the public record and decide for themselves. Dave Hollander*: Sometimes we just have to put a stake in the sand and go back and correct things. Stop throwing darts and start thinking about how to move ahead. You're moving ahead with MSL, but we need to do this more constructively. Phil Wadler*: As we've seen this morning, many clients find Schema perfectly usable. That's because they can pick out a subset that is not too complex and does what they need. XML Query has trouble because we're using schema as the type system and we have to use all of it, and so will other specifications like XSLT that wish to build on top of Schema. Now that Schema is at the Rec stage, how do move forward, continuing support for the users of Schema while ensuring Schema can be used as a foundation for XML Query, XSLT, and others. Response: We have a few weeks left before it's a Rec.

Sebastian Schnitzenbaumer*: XForms* wants to use schema, but maybe it should be modularized (like XHTML) so that it's much simpler. We have technology to solve this problem. We need simpler schemas and we'd love to use XML Schema if we could use a smalelr subset of schema. Let the market decide, let's modularize.

Part of LogicError. Powered by Blogspace, an Aaron Swartz project. Email the webmaster with problems.