W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

the case of two bats

From: Dan Connolly <connolly@w3.org>
Date: Tue, 16 May 2000 10:33:29 -0400 (EDT)
Message-ID: <39215C23.6171BA9C@w3.org>
To: xml-uri@w3.org
I'd like to discuss this issue in more black-and-white terms;
here's an example that has clarified the situation for at
least a few folks:

Consider two documents, one
at http://example.com/catalog/cat.xml :

        <inventory xmlns="../2000/vocab#">
                <bat qty="100"/>
                <ball qty="200"/>

and another at http://example.net/biology/animals.xml :

        <rodents xmlns="../2000/vocab#">

Are the <bat/> elements in both documents associated with the same
point in URI/web space? In other words, should this XSLT stylesheet,
with a base URI of http://example.org/tests/ ,
produce the same thing about each of them?


          <template match="lit:bat">
                lit: <value-of select="namespace-uri()"/>

          <template match="abs-com:bat">
                abs-com: <value-of select="namespace-uri()"/>

          <template match="abs-net:bat">
                abs-net: <value-of select="namespace-uri()"/>

Web Architecture, as I understand it, says that no, the two
<bat/> elements are associated with different points
in the Web, and that the stylesheet should produce

        abs-com: http://example.com/2000/vocab#

for the first document and

        abs-net: http://example.net/2000/vocab#

for the second one. This is what the XPath spec says too:

" The namespace
         URI specified in the XML document can be a URI reference as
         defined in [RFC2396]; this means it can have a fragment
         and can be relative. A relative URI should be resolved into an
         absolute URI during namespace processing: the namespace URIs of
         expanded-names of nodes in the data model should be absolute.
         Two expanded-names are equal if they have the same local part,
         and either both have a null namespace URI or both have non-null
         namespace URIs that are equal."
	-- http://www.w3.org/TR/1999/REC-xpath-19991116#dt-expanded-name

The namespace spec says that they have the same namespace
name: "../2000/vocab#" and the XPath implementations that I can find
behave as though the XPath namespace-uri() function should
return the namespace name per the namespace spec, rather
than actually conforming to the XPath spec. They
        lit: ../2000/vocab#
for both documents.

That's broken, no?

I don't exactly know what the cost of fixing those implementations ...

I gather the DOM spec and implementations follow this trend
of using namespace names as literal strings rather than references
that denote different absolute URIs depending on the contextual
base URI. But I haven't found a crystal clear statement of
this in the spec, nor have I found a test case that makes
it clear which way an implementation works.


The only answer that I can see that's consistent with
both the XPath implementations and Web Architecture is: "don't do that."
i.e. "The infoset for those document is unspecified. They conform
to the namespace spec, but only because of a bug that wasn't
caught; the namespace editors never intended to allow relative
URI references. Authors are cautioned not to create such
documents, since we have observed implementations that
are inconsistent with the XPath spec in this regard,
and we're not going to specify what DOM 2 does with them."

To say that the URI reference "../2000/vocab#" denotes
the same point in URI space regardless of the base URI of where
you found it is inconsistent with things like

        -- web browsers that turn anchors different colors
                based on whether the absolute URI denoted
                by the href="..." attribute value is
                found in your history list

        -- caches, proxies, metadata/annotation services, etc.
                that index things by (absolute) URI

i.e. it's inconsistent with Web Architecture.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Thursday, 18 May 2000 04:16:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:58 UTC