TAG Watch

April 3, 2002

Kendall Grant Clark

When, in late January of this year, I last peeked over the transom to watch the deliberations and review the work product of the W3C's Technical Architecture Group (TAG), its pressing substantive issues concerned the use and treatment of MIME media types in W3C standards, and it was also sorting out some of its own administrative procedures and processes.

Now that a full two months have passed, it seems a good time to look again at what the TAG has accomplished, what's on its agenda at the moment, and where it might be going next. In order to answer those questions, I will be examining the TAG's issues list, the progress and the discussion surrounding parts of its shared document work, as well as a practical issue or two.

The Issues List

Browsing the TAG's issues list is an excellent way to come up to speed with the group's work. (And, if I may be permitted an aside, the format and presentation of the issues list is very well done; many W3C and other Internet-based development groups would do very well to adapt TAG's issues list to their own work.) The TAG's policy is to acknowledge every request to resolve or address an issue it receives; however, its charter specifically disclaims any general W3C document oversight role: "The TAG is not expected to review every document on the W3C Recommendation track, only those that include Architectural Recommendations..." Thus, some issue requests are declined, while others are accepted. Once accepted, issues are assigned to one or more TAG members for resolution. Which is precisely what the issues list presents in a very compact, helpful form: the status of each issue the TAG has acknowledged.

TAG Declining

I have speculated, in previous comments about TAG in Deviant columns, that the TAG is likely to become a W3C bottleneck because of the rate of standards-change, technological development, and the sheer width and depth of Web technology (not to mention the always amorphously expanding boundaries of the Web itself, about which more below). Further, the work it is being asked to do is difficult, especially since its primary role is to make pronouncements about the hard questions. Thus, given these institutional and social factors, having the guts and the prudence to decline to address issues is going to be vital to TAG's long-term success. Saying "no", then, clears the way for being able to say "yes" at the right moments.

So far TAG has declined between a quarter and a third of requests: as of 2 April there were sixteen items in the issues list, five of which had been declined, including:

• a request to review the text of XForms 1.0 Last Call, which originated with the XForms Working Group;
• an invitation "to create liaison" with the Architecture Group of UN/CEFACT's ebXML project, which TAG suggested should be made to the Web Services Architecture Working Group;
• a request, raised by Tim Bray, to consider his "skunkworks" proposal about the next major version of XML (which I discussed in a Deviant column, "XML 2.0 -- Can We Get There From Here?"), which the TAG rerouted to the XML Coordination Group;
• a request, raised by Paul Prescod, to clarify the "appropriate relationship between SOAP RPC and the Web's reliance on URIs", which TAG rerouted to the XML Protocol Working Group;
• and, finally, a request, raised by Rick Jelliffe, to clarify whether proposed XML 1.1 changes run afoul of Unicode, an issue which TAG says XML Core Working Group is aware of.

Noteworthy patterns emerge clearly from this early data. First, some requests of the TAG should more properly be made of other Working Groups, i.e., the one most closely working on the technology or standard in question. Second, some requests shouldn't be made of the TAG at all, since they fall outside its charter. One thing the XML development community can do, then, to reduce the likelihood of TAG becoming a bottleneck is to carefully weigh whether and when TAG ought to address an issue.

In fact, the first objective sign that the TAG is overwhelmed, in at least one channel of communication, came on 1 April when Tim Bray said that the

TAG has a problem: we can't keep up with the volume of email on www-tag. This is a problem because it's part of the TAG's mandate to do our work in public. Furthermore, I have fond memories of the old XML WG, where we had a large and vociferous IG that gets a lot of the credit for coming up with good ideas and shouting down our lousy ideas.

In particular, several of us are intimidated by patterns such as the following:

- a posting from a TAG member gets a response where each original sentence is followed by multiple paragraphs of response
- threads that continue for 10 or 20 messages with no real new arguments being brought forward

Bray suggested a range of solutions, including restricting the kinds of messages that can be posted to the TAG list by requiring all messages to refer to an extant TAG issue or raise a new one, or limiting discussion to the forthcoming agenda items of the next TAG meeting, or simply by withdrawing posting rights to the TAG list from the general public, limiting them to read-only participation, and allowing on TAG members and Invited Experts to post. The response from non-TAG members seemed to agree that closing the list to others was a bad idea, especially since, as Michael Brennan pointed out, at least one TAG issue, the use of HTTP as a high-level protocol substrate, was raised in the course of free-form discussion. The most likely and (I think) the most reasonable solution is to form or find a (mostly unused and appropriate) alternative mailing list to shunt free-form discussion onto.

TAG Accepting and Assigning

TAG has, then, accepted eleven of the first sixteen requests that have been made in the period from about 9 January to 25 March. If the present rates of issue request and acceptance hold, and it seems likely that they will, the TAG will have looked at nearly fifty issues in its first year, accepting about 35 of those. Of the eleven issues accepted so far, the TAG has resolved three, which suggests a resolution rate of about one per month, though that rate is likely to increase (there are another two issues for which there is a partial or pending resolution).

Seasoned observers of the history of XML development, including the debates and discussions of the XML development community, won't be too surprised to see which issues have percolated up to the TAG for resolution. The issues which the TAG has accepted but not yet resolved include the following:

• a request, raised by Jonathan Borden, about development of an algorithm for turning a qualified name into a URI, an issue impinging upon the work of RDF Core and XML Schema Working Groups, which was raised on 22 January and has yet to be assigned to a TAG member;
• a request, assigned to Tim Berners-Lee and W3C/IETF liaison, to clarify when GET should be used in favor of POST, a request which the TAG itself subsequently expanded to include consideration of how to handle "idempotent queries";
• a request by Tim Bray to consider what a "namespace document" is, what it should contain, if anything, which was assigned to Paul Cotton, and about which TAG has reached a partial resolution: (1) namespace URIs should be "dereferenceable", but (2) there is no consensus about what sort of content it should contain;
• a request that the TAG clarify how to map URIs to media types, which was assigned to Stuart Williams, and which has a pending resolution in draft, which endorses Donald Eastlake's IETF work, with some qualifications;
• a request, raised by and assigned to Tim Berners-Lee, to clarify the canonical interpretation of XML documents with multiple namespaces, which is not yet resolved but for which there is a preliminary, draft document;
• a request, also raised by Tim Berners-Lee but as of yet unassigned, to determine the "range of the HTTP dereference function", that is, whether HTTP URIs, lacking a #-prefixed fragment identifier, refer to documents or to real-world objects (see "Fragment Identifiers on URLs" for more detail, as well as useful responses by Roy Fielding and Jonathan Borden);
• a request, raised by the W3C's Joseph Reagle and assigned to Tim Berners-Lee, to clarify under what conditions two URIs are equivalent, that is, the relation of canonical URIs and variants thereof;
• a request, raised by Mark Nottingham and assigned to Roy Fielding, about the W3C's view of RFC 3205, which suggests best practices in using HTTP as a substrate of higher-level protocols (for background, see the comments here and here).

Web Architecture Documents

	Also in XML-Deviant The More Things Change Agile XML Composition Apple Watch Life After Ajax?

In addition to the ad hoc, piecemeal work of responding to issues raised by the general Web and XML communities, the TAG is also working on (so far non-authoritative) documents addressing various issues of Web architecture. The TAG's Architecture Categorization seems to be serving as a kind of shared outline or roadmap of the parts of Web architecture which are slated for TAG documentation.

A large part of the TAG list traffic during February and March was response, discussion, and commentary on three documents which are part of the Architecture Categorization: "Introduction" by Tim Bray and Dan Connolly, "What Does a URI Identify?" by Norm Walsh and Stuart Williams, and "What Does a Document Mean?" by Paul Cotton and Norm Walsh.

There is not space in this column to review the discussion surrounding these documents, but I recommend that interested developers at least read the documents themselves. And I do commend to your particular attention the discussions about the boundaries of the Web itself, which highlight the tendency and the risk of the seemingly ever expansive reach, if not the grasp, of the W3C.

Conclusion

One thing that can be said with certainty is that the TAG is not shirking from addressing the most fundamental questions about Web architecture. As for the quality, clarity, and utility of the answers, that remains to be seen, but the discussions suggest that, at this still rather early date, things are proceeding along the right track. But, despite whatever infrastructural changes need to be made, I think it's also clear that the TAG's work must continue to be based on a reciprocal, mutual, and open conversation between TAG members and as many non-TAG Web and XML developers as is practical.

The kind of technological work the TAG is tasked with, like all forms of scientific, technical, and critical inquiry, is ultimately a thoroughly social undertaking. While for various marketing or motivational reasons, the romanticizing myth of the lone hacker or lone computer scientist solitarily creating works of mystery and wonder will likely persist for a long time, no one should forget that ultimately that solitary figure is as mythical as every other figure of romantic genius. It is well and good to stress the degree to which individuals, as opposed to corporations, are indispensable to the Web's past and future flourishing, but no one should forget that those individuals are always embedded in social processes in which collaboration, cooperation, and unfettered inquiry are, in the final analysis, the real engines of innovation.