Menu

Sunshine and Blueberries

July 11, 2001

Leigh Dodds

This week the Deviant reports on the impending formation of a new Web Architecture group within the W3C and provides an update on the state of XML Blueberry.

Web Architecture

The first indications that the W3C was going to form a group focused solely on Web architecture came at the Technical Plenary meeting held in February, which included a session devoted to Web architecture. Aaron Swartz, who attended the meeting as a member of the RDF Interest Group (the membership of which is open to the public) published notes from the meeting that referred to the Technical Architecture Group (TAG).

In a recent post to the www-talk mailing list, Janet Daly provided some additional background on the group and its origins, which apparently date back to last summer at the time when the xml-uri debate exploded into mail boxes around the world.

The first ideas for the TAG actually preceded the creation of the xml-uri mailing list...one in which Tim Berners-Lee relinquished his Director's role to engage in open discussion with the community at large. Lots of posts resulted, and there was initial praise from the community for the commitment to open discussion. However, it's safe to say that many of the participants, regardless of the position(s) they held, left with a wish for a different way to produce a solution. The experience reinforced the perceived need for architectural recommendations, though it didn't indicate who would write them, and what weight they should have.

To improve the effectiveness of Working Groups, to reduce misunderstandings and overlapping work, and to improve the consistency of Web technologies developed inside and outside W3C, the W3C Advisory Board, with input from the W3C Team and Members, developed the proposal for a TAG.

Any chance to avoid the kind of frustrating discussion that took place on xml-uri ought be welcomed with open arms. Daly expanded on her initial remarks about the desire for an architectural advisory group in a subsequent message.

There have already been many discussions on public W3C lists and elsewhere about the need for concerted efforts in discussing, describing, and defining Web architecture. In the early days of W3C, there was some measure of understanding about HTTP, HTML, and URIs (even if there was some dispute about what U, R, and I should represent). There was understanding that these should work, regardless of one's chosen operating system, or culture, or the graphics capabilities of a device. As the demands of Web users have grown in subtlety and complexity (not to mention scale), the technologies required have grown in complexity as well. Consensus, at the core of W3C work, is worthwhile, but it is not easy to find.

Given that there were already ideas for something akin to an advisory group which might produce explanatory documents, the TAG seemed like an idea worth pursuing. This is a growth effort, at making explanations and answering questions that all of us would like to see solved.

Trawling through the xml-uri archives one can find many mentions of "Web architecture" and associated "axioms", particularly from Tim Berners-Lee and Dan Connolly. However it's clear that not everyone shared the same views or even realized that these axioms existed at all. At one point Berners-Lee attempted to define the term "Web architecture", evincing early thoughts on the TAG.

The "Web Architecture" is a set of invariants, a set of assumptions which one can distill from the decisions which have been made historically and which we find have to be assumed implicitly within the web development community. My personal attempt represent these is at http://ww.w3.org/DesignIssues/Architecture and has been for 10 years.

The architecture evolves, of course. I brought this whole subject of how that should happen at the W3C Advisory Committee meeting. It is quite a tricky question. The architecture is not unquestionable. But some of it is the assumption on which people joined the consortium. What I would like is (current personal thinking) ... an ethos in which some documents represented the best stab at capturing the nominal important invariants at any one point, and a group within W3C or near neighbors would be expected to be aware of it and, if it wanted to go outside it, to negotiate it in a wider context than just itself...

In a later posting Berners-Lee noted that other groups had a similar means to plan future projects.

A group working together -- and that includes the public lists and open source -- need consensus systems, and they also need plans. Most other bodies such as OMG and IETF have some sort of formal or informal method of evolving the general direction, and of keeping individual contributions cooperative with it.

During the xml-uri discussion Dan Connolly posted a set of references that constituted the "axioms" of the Web. This ended up pouring more fuel on the fire, as none of these references had been accorded any official standing, being mostly a collection of design notes. But they make a good starting point for anyone wishing to dig further into the topic.

Open or Closed TAG?

It seems, then, that the idea for the TAG then has germinating for some time. Efforts to consolidate the existing design notes on web architecture will be useful progress, although its unclear whether there's any intention for the group to actually generate specifications itself.

The group has the potential to include both W3C members and external invited experts; however, the group will work in private rather than in a public forum like xml-uri. One could argue that this is too far a swing away from the fully open (but unmoderated and unguided) xml-uri discussion. It has certainly caused some consternation among the members of the www-talk mailing list, Aaron Swartz among them.

...In essence, the group will decide and define Web architecture in private. I think this is an awful decision for the future of the Web.

It saddens me enough that many important Working Groups conduct themselves in private (thankfully many important ones remain public), however, taking the entire Web architecture into this veil of privacy is a step too far.

Simon St. Laurent, a staunch critic of closed processes at the W3C was also moved to comment.

I'd certainly argue that the TAG should face maximum sunshine. I couldn't, in fact, be comfortable with a TAG that operates in anything less than full sunshine -- OASIS-TC-style at least.

...To put it bluntly, I'd like to see the W3C return to an attitude that Recommendations are effectively experimental, not fully-grown standards. If a TAG were to act as an additional level on the W3C which blessed successful recommendations and coordinated them, I'd congratulate the W3C on a wise move. If a TAG were to attempt to coordinate standards by enforcing adherence to various axioms which are considered immutable, I'd abandon what little hope I still retain for the W3C to be a help rather than a hindrance for the Web.

Others were less critical. They see promise in what the TAG might achieve. Al Gilman believed that it was a good move and would help to achieve consistency between "the bookshelf of W3C specifications" -- a prospect that will be welcomed by many.

Yes, the Technical Architecture Group is in the process of being put together, and it is a good thing for the Web. Without it, the W3C is at risk of either a) promulgating un-coordinated Recommendations that reduce the Web to chaos or b) spinning its wheels in endless internal coordination (just as private as, and less discoverable than, anything happening in the TAG) without getting the product out.

Note that at the same time that W3C is moving toward more centralized stuff (the TAG) to ensure consistency in the bookshelf of Web specifications, it is moving more of its business into the open (consider the process of the XML Protocol Working Group) to maintain its legitimacy and the public's trust that it is indeed seeking the good of all Web users, and not just the short-sighted interests of Members.

The official Charter for the group has yet to be published, although Janet Daly commented that drafts have already been circulated for internal review.

The second review of the TAG charter is nearly complete; provided there are no major issues raised in this last review, the document will be available shortly. I will make a point of sending an announcement to www-talk with the URI as soon as it is available.

Voting for membership of the group will likely take place after the publication of the Charter. It's probably safe to say that this won't be the only discussion of the TAGs goals and deliverables; the Deviant is sure the XML-DEV crew will give them a chewing over, once, that is, they've finished with the Blueberry...

Digesting Blueberry

Also in XML-Deviant

The More Things Change

Agile XML

Composition

Apple Watch

Life After Ajax?

Several weeks ago the Deviant reported on the publication of, and subsequent debate over, the XML Blueberry requirements ("Blueberry Jam"). These are aimed at expanding the level of Unicode support in XML to allow a wider range of characters to be used as element names.

Since then the debate has ranged between two positions: (1) concerns over changing XML to gain what many believe to be marginal benefits, and (2) the idea that greater support for Unicode (particularly the newly added scripts) is required for truly inclusive internationalization of XML markup. The opposing views are characterized largely by the views of Elliotte Harold (anti-Blueberry) and John Cowan (pro-Blueberry), to pick the two most prolific contributors.

Tim Bray recently enumerated the available options once more, and he noted that none of them made him feel particularly comfortable.

Realistically, there are 3 options:

  1. Leave it the way it is.
  2. Do Blueberry and then repeat the process for Unicode 3.2 and 4.0 and so on every couple of years forever.
  3. Bite the bullet, write the rules in terms of Unicode metadata and go to a pure use-by-reference architecture, probably adding a syntactic signal to reference the Unicode version number.

...But I really can't see how anyone can get behind any of these positions and feel entirely comfortable with where they find themselves standing. I sure don't.

James Clark has recently offered another proposal, on which, in typical James Clark fashion, appears to offer the simplest approach while meeting the base requirements.

Another bullet one could bite is to no longer make checking of name characters (beyond what is needed to prevent ambiguity) a part of well-formedness. Whilst it's nice to have some sanity checking of names, using inappropriate characters in names doesn't cause problems for further processing layers to the same extent as other things that are part of well-formedness do, such as unbalanced tags or duplicate attributes.

At least I think one should consider easing draconian error handling for bad name characters to reduce deployment problems with option 2.

The encouraging early responses suggest that Clark's proposal may lead to progress on handling what is turning out to be a particularly thorny fruit.