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

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
NS has neither persistence nor uniqueness it is no good as a NS
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
of the WWW should involve directly dereferencing namespace identifiers
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
URI should not resolve to an XML schema anyway.  Perhaps it should
to some RDF description or schema. If it must resolve to an XML Schema,
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
define well-known relative URIs which, when appended to the NS
give standard locations for various kinds of schemas and information.
example, to find schemas and DTDs, RDF schemas, default stylesheets,
stylesheets, editing tools, etc.  Each WG should define the appropriate
well-known relative URL for locating the kinds of resources they deal
relative to a NS identifier: for example, the HTML WG could specify
locations for the various DTDs and schemas and WAI schemas for XHTML,
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
PI allow retrieval of document resources from locations not controlled
the body in whose domain the namespace URI participates.  (Some
mechanism, perhaps.)

So this failure in architecture comes from a failure in policy: that
you make a markup or stylesheet language for a particular application
domain, you need to set in place the architecture to support it.  This
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
Clark was to push ahead with the stylesheet PI!  We have in the Web a
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
can specify the XML application to be used or whatever: but when we get
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
solutions (such as the current relative NS issue.)

The relative namespace issue is a symptom not the disease.  It needs
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