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

Re: the case of two bats

From: David Carlisle <davidc@nag.co.uk>
Date: Thu, 18 May 2000 10:19:41 +0100 (BST)
Message-Id: <200005180919.KAA18594@nag.co.uk>
To: xml-uri@w3.org

> Consider two documents, one

I agree with all of your example (except the conclusion:-) but instead
of 
> Consider two documents

can I modify it slightly so that the two documents are copies of each
other. The expectation of most people (and backed up I would claim by
the xml and namespaces rec, but not by xpath, as you rightly point out)
would be that moving the document from
http://example.com/catalog/cat.xml
to 
http://example.net/biology/cat.xml
(which might not be a move at all, just a different retreival process)
would not change the (expanded) names of all the constructs in the file,
thus breaking the stylesheet (and other things) for the document.

> 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

To say that is not what the NS spec says, it says that 
the namespace name is the URI reference, ie "../2000/vocab#" 
the fact that the two URI references  "../2000/vocab#"
and "../2000/./vocab#" refer to the same absolute URI (for any given
base) is not at all inconsistent with the statement that the two 
URI references are two namespace names.

Tim Berners-Lee said

> Had I thought that the meaning was to discourage the use of the NS URI
> to point to a schema, then I would have objected most strongly at the
> time.

If you read the namespace spec as written, without any preconceptions
about why namespaces are there at all, I think you'd have to agree that
`discourage' isn't a strong enough word. Namespace names as described
in the namespace rec are just names, they don't point at anything.
The URI syntax is just used so that by using as the name, a URI over
which you have control, you can allocate a unique name with no clash
with namespaces defined by other people.

That was my reading of the spec as an `outsider' not having taken part
in any of the discussions leading up to the document (and as far as I
can see that is the reading of most people who are similarly coming from
the outside) It has also I think been confirmed as a reasonable (if not
unique) reading by the spec's editors on xml-dev, and this list and other
places.

What I can't understand is why you would want to force the same
mechanism for both locating a schema document and for the namespace.

If I have an XML document containing some MathML elements  in the namespace
http://www.w3.org/1998/Math/MathML
that name uniquely identifies the construct as MathML, and this fact
is used to dispatch those elements to MathML module of whatever software
is processing the whole document.

However independently I might in the document want to point at a copy of
a DTD or schema that describes the whole document, we could assume for
simplicity that the document just consists of MathML,
so I can use
SYSTEM "any/uri/to-a-copy-of/mathml2.dtd"
or
xsi:schemaLocation="any/uri/to-a-copy-of/mathml2.schema" (once this is written)

I don't expect that by changing the system literal to point to a local
copy of the DTD that I suddently make all the elements not MathML, and I
don't want that to be the case for xsi:schemaLocation either,
but if I change
xmlns="http://www.w3.org/1998/Math/MathML"
to
xmlns="any/uri/to-a-copy-of/mathml2.schema"

then the elements are no longer in the MathML namespace, and are not
MathML. Saying `they are not MathML' is not just an academic argument
existing namespace aware MathML systems (Mozilla, XSLT MathML
stylesheets, my TeX based XML typesetting system, ...) all will
fail to recognise the elements if the namespace URI is changed.

If there is a canonical copy of a schema document at the namesapace URI
then there is nothing wrong with that, but you should be able to point
to a local copy of the schema document with xsi:schemaLocation
without changing the namespace.

David
Received on Thursday, 18 May 2000 05:20:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC