Re: Layering XPath/XSLT namespaces is unacceptable

I was very glad to see this message. I agree.

Further, the same argument which you apply here to XSLT and XML
(that they can't be in different layers with different notions of identity)
can be used similarly for RDF.  RDF cannot be considered
as some "application" which can use a different notion of identity.
RDF uses a 1:1 mapping between RDF properties and XML element types.
You can't have different implementation of identity for these. Paraphrasing
your point,

"An RDF 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 compared by
> reference.  If RDF 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
>RDF results to be returned to another, orthogonal service, since all of the
>names would be different...

Similarly, and knowledge system built on top of RDF will be able to add many
new features but they won't be able to have a different notion of identity
of properties.

    Tim BL

PS: Some of the latest RDF tools Dan has are built using XSLT.
PPS: One man's ceiling is another man's floor.
PPPS: One man's sealing is another man's flaw.

-----Original Message-----
From: Michael Champion <Mike.Champion@softwareag-usa.com>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Wednesday, June 14, 2000 11:38 AM
Subject: 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 17:27:16 UTC