Why are relative NS identifiers used?

We cannot expect Microsoft and others who use relative NS identifiers to
stop using them unless the new solution allows them comparable
functionality.

Relative NS identifiers are used, apparantly, to locate schemas.

I don't think it can work merely to say (with Tim Bray) that because a
relative
NS has neither persistence nor uniqueness it is no good as a NS
identifier.
Not because Tim is incorrect, but because the relative NS URIs are not
being primarily used here for naming but as schema locators. 

Nor will it work to keep on avoiding this issue: if Tim BL thinks the
architecture
of the WWW should involve directly dereferencing namespace identifiers
to 
get schemas, then he should put it up as a formal proposition and either
get it voted
on by W3C or declare it by fiat for W3C technology.

The Schema WG has not gone down this route. The reasons are
 1) performance
 2) it is not the XML Schemas job to say what a NS URI resolves to.

If we are talking about the semantic web, it is quite likely that the
namespace
URI should not resolve to an XML schema anyway.  Perhaps it should
resolve
to some RDF description or schema. If it must resolve to an XML Schema,
that
is not the "semantic" web but the "type-based web": we would know that
something is
a date but not what it is a date of or for.

This is an architectural failure at the W3C. What is needed is

 1) A revision of the namespace wRECk to add a mechanism where W3C WGs
can
define well-known relative URIs which, when appended to the NS
identifier,
give standard locations for various kinds of schemas and information.
For
example, to find schemas and DTDs, RDF schemas, default stylesheets,
WAI-specific
stylesheets, editing tools, etc.  Each WG should define the appropriate
well-known relative URL for locating the kinds of resources they deal
in,
relative to a NS identifier: for example, the HTML WG could specify
various
locations for the various DTDs and schemas and WAI schemas for XHTML,
the 
NS URI for HTML being the root for these.

 2) Non-NS-identifier-based mechanisms for locating document resources. 
For example, the XML Schema WG schema location mechanism and the
stylesheet
PI allow retrieval of document resources from locations not controlled
by
the body in whose domain the namespace URI participates.  (Some
XLink-based
mechanism, perhaps.)

So this failure in architecture comes from a failure in policy: that
before
you make a markup or stylesheet language for a particular application
domain, you need to set in place the architecture to support it.  This
applies
to XML Schema just as much as RDF or stylesheets.

Microsoft uses relative NS identifiers to retrieve schemas because the
W3C has
failed to provide any other mechanism for retrieving schemas. How wise
James
Clark was to push ahead with the stylesheet PI!  We have in the Web a
beautiful 
tree, where IP packets can specify TCP or whatever, and TCP can specify
HTTP or whatever,
and can HTTP specify the MIME type or whatever, and the MIME handler
registry
can specify the XML application to be used or whatever: but when we get
to 
supposedly extensible XML, we suddenly halt. We can specify different
DTDs (thanks to SGML) and different stylesheets (thanks to James Clark)
but can we specify anything else (except privately)?

No, suddenly we go from a thriving world based on allowing a plurality
into a void or dead-end. I think this comes from the idea that there
should be one single schema language and one single stylesheet language
and so on, which some people have. It might be argued that this kind
of extensible mechanism just plays into the hands of large monopolizing
companies: on the contrary, not having any mechanism guarantees
home-made
solutions (such as the current relative NS issue.)

The relative namespace issue is a symptom not the disease.  It needs
more
than a bandaid (which is not to deny that it at least needs a bandaid.)


Rick Jelliffe

Academia Sinica Computing Centre

Received on Thursday, 18 May 2000 04:43:21 UTC