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

Re: Thoughts from an external observer

From: David Carlisle <davidc@nag.co.uk>
Date: Tue, 23 May 2000 14:16:08 +0100 (BST)
Message-Id: <200005231316.OAA20078@nag.co.uk>
To: vdv@dyomedea.com
CC: xml-uri@w3.org

> I would have expected at least some acknowledgment

Sunday afternoon? Was sowing vegetables in the allotment, there are more
important things in life than XML you know:-)


> you'll have guessed that it's from the RDF "Model and Syntax Specification",
> chapter 2.2.3. "Schemas and Namespaces".

Sigh. rdf's use of namespaces just seems to be irretrievably broken.
If any spec needs fixing, that must surely be first in line.

> 3 examples of applications doing so have been mentioned so far :

   <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
                       xmlns:DC="http://purl.org/dc/elements/1.0/">

   <Schema name="Schema" xmlns="urn:schemas-microsoft-com:xml-data"
    xmlns:dt="urn:schemas-microsoft-com:datatypes">

     xmlns:math="http://www.jclark.com/xt/java/java.lang.Math"

All those examples use absolute URI so arguably are out of scope for the
discussion, but they do usefully show how other specs can usefully use
the namespace URI for whatever purpose they want, including retrieving
stuff, but do it in ways that don't break the primary use of namespaces
which is to give a structured name to XML constructs, with a name
consisting of a pair (URI reference, XML 1.0 Name).


> Are the applications supposed to guess if they will find a XSchema, a
> RDF schema or anything else when they follow the URIs ?

Quite, which is why a schema validator ought not follow a random
namespace URI in a document. An xpath expression evaluator, if it sees
math:sin( knows that the prefix is being used in an extension function
so can look up the URI reference bound to the prefix and choose the 
appropriate class. Its interesting to note that saxon's version 
of this allows absolutely any URI at all
xmlns:math="what/ever/you/like/java.lang.Math"
would work. If the prefix is used in an extension fuction the last
component of the URI reference bound to thet prefix is used as a
java class name. I have no idea what a schema validator would make
of such a document if it tries to follow such a URI, it could find
anything at all (nothing most likely). Having a schema validator
follow namespace URIs has no virtues at all as far as I can see.

> Why couldn't we follow the suggestions to keep the namespaces as a
> mechanism to disambiguate names and add a separate mechanism to link the
> resources associated with the namespace ?

We could follow that suggestion. We should.

> If we accept relative URIs (from my reading of the various specs) in
> addition to what has been said about XPath, the xslt processors will
> need to be updated to change the namespace in the output tree.

You mean here if we accept the change to make URI refs absolute .

With the literal interpretation The XSL system need never check whether
the URI reference is absolute or relative, both work equally well.
That is they both work equally well to a namespace aware system.
Given that the reason for using URI syntax at all is stated in the
namespace spec as allowing the production of globally unique names
then clearly if you chose not to make the name globally unique
then that is bad style perhaps, but often you don't really need to claim
such global status, so I see no real reason to ban it.

Being globally unique isn't the same as being an absolute URI.
mailto:david file:///david, data:,david are all absolute, but not
globally unique.  So it's just a matter of good style, that if you want
to use your namespace in multiple documents in multiple environments you
ought most likely pick a sensible URI, but for one off stylesheets, and
small test cases I can't see a lot of point in banning it now. It just
adds an extra check on the system and it makes invalid some existing
documents.


David
Received on Tuesday, 23 May 2000 09:17:00 UTC

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