RE: Static resolution of names is preferred over dynamic resolutionof na

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.

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.

Comments?

/Roger