more QName madness

The reportedly soon-to-turn-into-a-pumpkin XLink Working Group has
blessed us with yet another round of drafts for XPointer, releasing a
trio of Proposed Recommendations. [1-3]  The foundation PR, the XPointer
Framework[1], both opens up the prospect of other developers creating
XPointer schemes and burdens them with extra namespace baggage that the
W3C reserves only to itself the right to avoid.  

How?  The magic of QNames.  

Once upon a time, we had QNames which represented element and attribute
names, and, per the Namespaces in XML specification, processors
interpreted those compound names according to a declaration context
created by the surrounding document.  Despite many howls of protest and
years of discussion about what this mechanism really does and how it
works, QNames used as element and attribute names are now pretty tightly
integrated into the XML processing fabric.

For example:
<species xmlns="http://simonstl.com/ns/species
         xmlns:html="http://www.w3.org/1999/xhtml">
   <commonName>Cuckoo Possum</commonName>
   ....
   <description>
   <html:p>The Cuckoo Possum is a mythical creature whose habits are not
well known, except insofar as they involve invading the pouches of other
possum species to place their own young there.  The demented creator of
the cuckoo possum, <html:a href="http://simonstl.com">Simon
St.Laurent</html:a>, claims that it was just a joke for a book
example.</html:p>
   </description>
   ....
</species>

The next step forward in the use of QNames came when XPath needed a way
to reference elements and attributes that used QNames as identifiers,
and it was fairly clear that expanded names (roughly URI+localName)
weren't going to be popular.  XPath solved this riddle by letting
stylesheets use QNames inside of XPaths, using the namespace context
that applied to the point where the XPath appeared in the stylesheet.
(Of course, there were problems with using the default namespace, but
after being bitten once or twice or ten times, most XSLT developers
adjusted.)

For example:
<xsl:stylesheet version="1.0" 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:s="http://simonstl.com/ns/species"
  xmlns:h="http://www.w3.org/1999/xhtml">
....
   <xsl:template match="/s:description/h:p">
   ....
   </xsl:template>
</xsl:stylesheet>

The next step forward in the use of QNames came when W3C XML Schema
decided that it would use QNames to identify types, not just element or
attribute names.  Processors of these QNames once again had to sort out
the context for the QName, but W3C XML Schema enshrined its own practice
in a new "QName" type for values, and QNames suddenly received use as
values independent of their use as element or attribute names.

....
 <xs:attribute name="html:a" type="xs:anyURI" />
....

The next step forward in the use of QNames came in XPointer, where it
became clear that reusing XPath in the xpointer() (and eventually
element()) scheme would require a notion of namespace context that XPath
didn't itself include.  To ensure that fragment identifiers which
depended on navigating element or attribute structures could find their
way, the XLink Working Group created the xmlns() scheme, letting
developers define namespace declarations inside of the fragment
identifier.  Robust URI references shouldn't depend on a particular
processing context, right?

....
   <link
xlink:href="http://simonstl.com/fairytale#xmlns(s=http://simonstl.com/ns
/species)xmlns(h=http://www.w3.org/1999/xhtml)xpointer(//s:description/h
:p/h:a)" >...</link>
....

The next step forward in the use of QNames came today, when the XLink
Working Group made a large change in the nature of XPointer scheme names
between Candidate and Proposed Recommendation status.  If you choose to
believe the Proposed Recommendation, XPointer scheme names are QNames,
and only the W3C is permitted to use unprefixed names in the effectively
default namespace.  QNames now exist as fragments of fragment
identifiers, forced to carry namespace declarations in the XPointer
parts to their left.

....
   <link
xlink:href="http://simonstl.com/cuckooPossum#xmlns(s=http://simonstl.com
/ns/species)xmlns(h=http://www.w3.org/1999/xhtml)xmlns(s=http://simonstl
.com/ns/xpath1)sxp:xpath1(//s:description/h:p/h:a)" >...</link>
....

At what point in all this forward motion did the process go over a
cliff?  There were clearly signs at the beginning of the journey, but it
is quite remarkable how far this trip has continued since.  It would in
fact be quite amusing, except that I'd actually like to use XPointers
sometime in the relatively near future and now consider them such an
incredible botch that it's time to throw out the specifications and let
someone else try again.

It's really quite something to see a gHorribleKludge grow and grow and
grow worse over the course of years.  Amazing, even before you pause to
consider that the W3C has reserved the rights to far less verbose usage
to itself when plans for future scheme development are cloudy at best.

[1] - http://www.w3.org/TR/xptr-framework/
[2] - http://www.w3.org/TR/xptr-element/
[3] - http://www.w3.org/TR/xptr-xmlns/


-------------
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:1.3.6.1.4.1.6320 is another possibility altogether