- From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
- Date: Thu, 22 Jun 2000 16:48:48 -0700
- To: <keshlam@us.ibm.com>
- Cc: "David Carlisle" <david@dcarlisle.demon.co.uk>, <abrahams@acm.org>, <xml-uri@w3.org>
> >, in the latter really common. > > We emphatically do NOT agree. As has been discussed repeatedly, there seems > to be little or no advantage to using a relative reference to the namespace > identity. There are certainly potential advantages to having the _next_ > level of binding -- from the namespace identity to the semantics you wish > to apply to it -- be aware of the context in which you are manipulating the > document. But having the basic identity of the element or attribute change > when it's viewed locally rather than remotely is much more likely to > introduce breakage than it is to confer benefits. I am sorry if I have missed some of the points made on this but I am in fact not talking about changing the identity or the semantics depending on whether you use local file vs http lookup if that is the scenario that you have in mind. Let me clarify what I have in mind: I can have 5 documents that are interlinked in a completely consistent and integral manner with relative URIs. Of course, even though the URIs are relative, I have to ensure that the relative URIs follow the rules dictated by the URI space indicated by the URI scheme of the base URIs for the 5 documents. However, assuming that I have done this, I can move them around in the hierarchy defined by that URI space and still have all relative links within the 5 documents be consistent and not affect the integrity of the documents. > Relative URI references are a fine thing when you Really Want an operation > to be context dependent. Identity should not be context dependent. But they are always context dependent - this is true for all names as all names are relative to something. For DNS, I can set up a new Internet and introduce DNS there and have all my links in the existing Internet work in that new world because all DNS hostnames will then be relative to the new Internet. Relative URIs are no different in that regard but they allow me to define namespaces on any node that may in fact not even have a DNS entry - for example pretty much any host using DHCP because I can define the constrained context they work within. If I can't do this then I will have to use "http://localhost/" which is really just relative to where you are. > >One thing that I am sure about is that if the latter case is going to be > >the common case then people are going to use relative URIs regardless - > >otherwise they can't do what they want to do. > > I still have not seen a use case where they "can't do what they want to do" > if we forbid relative references to namespace identity. The examples which > really _need_ relative all focus on that next step of going from identity > to metadata -- and are well served by either explicit bindings from > namespace to a _seperate_ relative URI, or by using a catalog to perform > that mapping, and I expect other mechanisms are also possible. Henrik
Received on Thursday, 22 June 2000 19:49:24 UTC