Re: Why are relative NS identifiers used?

>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.


<METAPHOR>


But that use as schema locators is in no way supported or guaranteed by the
Namespace Spec. This is something like buying a screwdriver, reforging it
into a hook for pulling a spring into place, then going back to the
manufacturer and complaining because it no longer drives screws well.

In fact, Sears will let you get away with that, for purely political
reasons -- ie, they've found that it's less expensive for them to hand you
a new screwdriver than to waste time arguing with you. Most other
manufacturers will tell you that when you decided to modify the tool you
voided their warranty.

The question on the table is whether we want to let an abuse of a tool
shape future _correct_ use of the tool... and if so, whether we do so by
ignoring it or by modifying the tool to actively support it, possibly at
the cost of making the tool less effective/efficient for the community that
it was originally designed to serve.

My own reaction: If folks really spring-pullers, we should design and
market a spring-puller. Maybe even one that snaps onto their existing
screwdrivers. But making the screwdriver less able to serve its original
purpose is _not_ a net service to the customers.


</METAPHOR>



>Microsoft uses relative NS identifiers to retrieve schemas because the
>W3C has
>failed to provide any other mechanism for retrieving schemas.

The W3C's XML Schema working draft proposes several such mechanisms.
Microsoft's just having the same problem we all face in that even when
development is sped up to web-years the answers do take a little while to
become available. If you run ahead of the standards, you accept the risk
having your solution declared incompatable with them, in exchange for the
opportunity to start experimenting earlier and perhaps drive those
standards... but there is no guarantee that your solution will be accepted.

None the less, if we can find an answer that doesn't break Microsoft's
files _OR_ break existing W3C specs, that's probably best.


Forbid breaks Microsoft's files and possibly other existing practices.
     (Unfortunately the Namespace spec didn't forbid relative names, though
I believe
     Tim Bray has said they never intended to permit them..)
Literal, we're told, breaks assumptions that "if it looks like a URI it
must be a URI"
     (Of course, so does any other occurrance of URI syntax in a document's
text.)
Absolutize breaks the Namespace spec
     (Documents in this category would not be processable by
namespace-aware applications,
     which to me means they aren't namespaces.)


I'm still desperately hoping that someone will find something new to say
that will break this deadlock. But I think it's going to come back to being
a majority vote with a disgruntled minority.


>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.

I don't think that's an issue in this discussion. No matter which
metalanguages you use, there's the same quesiton of how an instance
document binds to them... and the same argument over whether the Namespace
Name must be usable as a direct binding, when that was _not_ a goal of the
Namespace spec.

Received on Thursday, 18 May 2000 09:47:04 UTC