Layering XPath/XSLT namespaces is unacceptable

I've supported the notion of "layering", i.e., that specs built on top of
XML might insist that their implementations absolutize namespace URI
references even though relative URI references are deprecated, forbidden,
literalized, or whatever in XML itself.  I still agree that this might be
useful for RDF, but have become convinced that XPath/XSL must not "layer" a
different namespace URI interpretation from XML's.

This is based on an important practical consideration: XPath and XSLT are at
the very core of what our company, and many others, use to build XML
implementations and applications. An XSLT/XPath implementation should build
upon the events/node-tree from the namespace-enabled XML
parser.   Such a parser could (and in many cases does)
intern names so that identical names can be comparied by
 reference.  If XSLT/XPath requires a different notion of
"naming" than the lower layers, it invalidates work done
by the lower layer.  Also, this would make it difficult for
XPath results to be returned to another, othogonal service, since all of the
names would be different...

We see XPath/XSLT as core infrastructure items, which will
be implemented in conjunction with the parser and
schema validation system.  XPath/XSLT is *not* in
the "application" layer and thus does not have the
right to re-define the meaning of "qname".   RDF seems to use XML more as
a serialization format, and hence *is* in the application layer,
AFAIK.

Thus, it may make perfect sense to have the relative URI semantics supported
by RDF, or other "semantic web" systems ON TOP OF XML. Waving our hands and
saying something about "application layering" is not a solution for XPath,
XSLT, and Schema (and probably others) because they should be considered to
be tightly coupled with the very core of XML.

Received on Wednesday, 14 June 2000 11:38:17 UTC