Hi
Folks,
Thank
you for the outstanding and insightful discussion!
Special thanks to Michael Kay, Ghislain
Fourney, Stephen
Cameron, and Rick Jelliffe.
Below is a summary of what I learned from the discussion.
Any errors in my summary? Anything you would
add or
delete? /Roger
Way back in
the early 2000’s, the namespace working group made a
decision to allow QNames in data. If the working
group had instead decided that QNames are allowed only in
markup, then XML parsers could exclusively handle all the
complexity of namespaces – parsers alone would be
responsible for determining the expanded name of markup
(elements and attributes). As a result, parsers would be
able to provide a simple API for their parse trees. Each
element node in the parse tree would contain (among other
things) the element’s local name and expanded name.
The
following two sentences are key:
1. QNames
are allowed in data.
2. XML parsers do not process QNames in data.
Those
two sentences have enormous ramifications:
(a)
XML
parsers must assume that lurking inside markup may be
QNames that the parser has not (and cannot) handle.
Consequently the parser must provide a complex API, an API
that exposes all the namespace complexity – which namespaces
are in-scope, what namespace prefixes are bound to which
namespaces, etc.
Ramification
#1: Due to the namespace working group’s decision to allow
“QNames in data” the parser’s API must necessarily be
complex.
(b)
XML applications build on top of XML parsers. XML
applications take the output produced by an XML parser and
use it as input to the application. Specifically,
applications use the parser’s API for accessing the parse
tree. Since the parser is not able to resolve all of the
QNames, it’s incumbent on XML applications to deal with the
unhandled QNames (and namespaces).
Ramification
#2: The task of dealing with the complexity of namespaces
must be dealt with by both the XML parser and XML
application. Instead of being confined to just the XML
parser,
the task of dealing with namespaces has leaked outside
the parser into higher-level XML applications.
The
simple, seemingly innocuous decision back in the early
2000’s by the namespace working group to allow “QNames in
data” has had huge repercussions. Consider the time and cost
that the world-wide XML community has spent in the last 16
years on incorporating namespace-handling code in every XML
application. Consider the time and cost spent on
implementing complex XML parser APIs.
Well,
the
impact is done. Can it be undone? Should it be
undone? It should be noted that
“QNames
in data” has been put to good use in some XML applications.
For instance, XML Schema uses QNames in data extensively:
the value of the type attribute in the following schema is a
QName.
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.elevation.org"
xmlns:elev="http://www.elevation.org">
<simpleType name="EarthSurfaceElevation">
<restriction base="integer">
<minInclusive value="-1290"
/>
<maxInclusive value="29035"
/>
</restriction>
</simpleType>
<xs:element name="BostonElevation" type="elev:EarthSurfaceElevation"
/>
</schema>
XSLT
also uses QNames in data: the value of the name attribute in
the following stylesheet is a QName.
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:fn="http://www.function.org"
version="2.0">
<xsl:function name="fn:example">
...
</xsl:function>
</xsl:stylesheet>
Lessons
Learned:
(1)
Small
decisions may have a huge, long-lasting impact,
financially and other ways.
(2)
When
creating a data specification no decision should be
treated lightly. No decision is simple or innocuous.
(3)
Always
implement a parser before publishing a data specification.
Carefully assess the parser’s API for its impact on
higher-level applications.
