- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 24 May 2000 12:11:19 -0700
- 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