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

RE: A little courtesy, please

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 24 May 2000 12:11:19 -0700
Message-ID: <116DFD732FA92E4D9B647C8EEF6DAF1015E1FD@red-pt-02.redmond.corp.microsoft.com>
To: "'Tim Berners-Lee'" <timbl@w3.org>, xml-uri@w3.org
> -----Original Message-----
> From: Tim Berners-Lee [mailto:timbl@w3.org]

> The namespace spec, we now realize, breaks relative URIs as 
> defined in an IETF specification of long standing and great 
> use.

Accepting that as true for the moment, what do you propose to do about it?

To bring Namespaces into line with the expected handling of relative URIs
means that each document must have a base URI at all times, which is
currently not the case.  Otherwise, a case of "disappearing names" results.
Is making something as fundamental as element names context-sensitive a good
design?  I don't see how it could be, and David Carlisle has done a good job
of providing examples and scenarios of the dangers involved.

So if we absolutize for the sake of URI consistency, we also have to forbid
relative URIs so that names are indepedent to changes of document location.
Of course, if we forbid, we no longer have to absolutize.  Absolutization
and forbidding amount to essentially the same thing.

While I was initially fairly open about whether absolutization or literal
string comparisons is the right way to go, forbidding clearly is impossible
without either breaking trust in the W3C or versioning Namespaces, as
forbidding is incompatible with existing docments in both theory and in
practice.

If we do version Namespaces, what compelling benefit is there to adopt it?
Nothing concrete that I can sell to customers except a promise of the hassle
of changing all their document version numbers, and so a new version is
susceptible to becoming an intellectual excerise and not solving real
interoperability problems.  If you recognize that and want to go ahead with
it anyway, fine - but don't complain if adoption flops.

In order to elicit more response from you about this problem, I'll
re-propose a hack that attempts to address the competing demands of URI
conformance and name stability.  Note that I'm not _advocating_ these
positions.

1) Define somewhere (XML Base?) that all XML documents in which the base
cannot be determined default to a constant value for their base URI.  Thus,
documents can never be in an environment where base URIs don't exist, and
names can always be determined.  Then choose that either ...

 a) Relative namespace URIs can be declared as always relative to this
constant base value.  Thus we fulfill the letter of the URI spec, but names
do not vary based on their location.  Or...

 b) Relative namespaces are relative to the base of the document and
xml:base.  Thus names always exist, but aren't stable across contexts (which
is incredibly bizarre, is tractable in current practices I'm aware of).

You will note that (a) is in practice the "literal" approach but it
exchanges circumvention of the URI spec for allowable freedom in media types
choosing their mechansism for determining base.

If you have any better ideas on how to reconcile URI conformance and name
stability, I'd love to hear them.  If they aren't reconcilable, it comes
down to a judgement call (which appears to be the current state of
discussion) and I'd be interested to hear your view on why name stability
should lose out.  So far you've done a good job I think explaining why URI
conformance is a good thing, but not why name stability is not also a good
thing, or why URI conformance is more important than name stability.

- Jonathan Marsh
  Microsoft
Received on Wednesday, 24 May 2000 15:13:47 UTC

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