- From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
- Date: Tue, 20 Jun 2000 08:25:59 -0700
- To: <abrahams@acm.org>, "Graham Klyne" <GK@dial.pipex.com>, <XML-uri@w3.org>
> No, I'm not passing judgement on the intent of the proposal. I'm just saying > that until the proposal clearly and explicitly defines what is meant by identity > of namespace names, however it chooses to do that, it really should not be > considered seriously. If not done already [1][2] then please let me reiterate the following clarifications of the proposal: a) What the comparison rules are: It is correct and sufficient if a basic consumer only uses octet-by-octet comparison taking into account relative URIs. However, it is also fully acceptable for the consumer to know about special normalization rules of a URI space and apply those if so desired. In particular, the URI spec describes normalization rules for commonly used constructs like DNS host names. b) Why comparison rules weren't put into the text directly: Because that is really describing URIs in general and hence doesn't really belong in either the HTTP spec or the NS spec. c) Responsibility of a namespace provider: The generator of a name has the responsibility to know the semantics of the URI space that she is using so that for not different semantics are assigned to http://www.ms.com vs http://WWW.MS.COM d) Responsibility of a consumer: The consumer is responsible handling relative URIs within the context that they are defined. In general, the context is defined by the URI space itself and may not be explicit in the URI. Therefore, in order to know and use these properties of a name, it is necessary to know the context (ie properties) imposed by that URI space. e) Good Practices: In the NS spec we should encourage people generating documents to be consistent about the use of URIs so that simple mistakes are avoided Henrik [1] http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0721.html [2] http://lists.w3.org/Archives/Public/xml-uri/2000Jun/0697.html
Received on Tuesday, 20 June 2000 11:27:02 UTC