- From: Graham Klyne <GK@NineByNine.org>
- Date: Mon, 07 Jan 2002 13:27:40 +0000
- To: www-tag@w3.org
At the December 2001 IETF meeting, I engaged in a discussion about how some well-established Internet "access" protocols might look if they were mapped to use XML for their basic protocol-unit structure (think of IMAP, ACAP, LDAP, etc.). The person with whom I was talking had considered that XSLT might be a common basis for selecting information to be accessed -- currently, these protocols all have their own ad-hoc way of doing this. (Of these, I think that LDAP has a relatively clean access-specification model.) And, yes, I can see that XSLT *could* be used in this way, even if (a) it's not at all what XSLT has been designed to do, and (b) it is seriously overkill for the task in hand. My response was to consider XQuery for the same purpose, and subsequent perusal of its specification draft did seem to indicate that it was about right for the purpose being explored. So what's this to do with Web architecture? It struck me that a very experienced protocol designer had managed to pick the "wrong" XML tool for the job. It also seems to me that there is an architectural difficulty when there are different tools in the XML family that can be adapted to perform the same function. (To be fair, there are mitigating considerations: (a) both of the tools make heavy use of the common XPath specification, which provides much of the needed functionality, and (b) XQuery is not yet out of working draft status, so might easily be overlooked.) But the overlap of functionality remains, and I think this is something which we would prefer to avoid in the overall Web architecture. For example, I could imagine a variant of XSLT being specified as a wrapper around one or more XQuery expressions. This is an observation, and I don't really think that we should try to do anything about XSLT/XQuery at this stage. But I think it illustrates a kind of issue to which I hope the TAG can be sensitive, and provide some early guidance to build web architecture as a neat tessellation of interlocking pieces, rather than ending up with a tangle (I was tempted to say "web") of significantly overlapping specifications. #g -------------------------- __ /\ \ Graham Klyne / \ \ (GK@ACM.ORG) / /\ \ \ / / /\ \ \ / / /__\_\ \ / / /________\ \/___________/
Received on Monday, 7 January 2002 08:48:55 UTC