- 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