- From: <keshlam@us.ibm.com>
- Date: Thu, 22 Jun 2000 19:47:05 -0400
- To: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>
- cc: xml-uri@w3.org, "David G. Durand" <david@dynamicDiagrams.com>, masinter@attlabs.att.com
>My point is that somebody defining a namespace MUST NOT assign different >semantics to two names that according to the properties of the URI space >are the same name. Reminder: It is not at all clear at this time that the person defining the namespace is in fact defining semantics in any strong sense of the term. It is certainly _preferable_ if everyone agrees that a particular expanded name should be used for specific purposes. But there is nothing in today's architecture which documents that intent, never mind acts on it or enforces it. It may be reasonable to expect that {http://usps.gov/mailingAddress}City will in fact be used to refer to the name of the city to which the addressee's mail will be delivered. But if someone decides to reuse that datatype to specify a city for other kinds of deliveries, that's fine. If they decide to use cities as the names of a particular level of their network hierarchy, independent of whether the servers are located in those cities or not, that's a bit weird but also fine. And if one really insists on writing a schema in which that same expanded name encodes cities as numbers rather than names, or uses it as the root element for a description of the city, or uses it as a flag to distinguish things that are legally incorporated as Cities (versus Townships or Villages), or to refer to a fictitious city in an interactive novel ("See the Milky Way on 7 megaergs a day!").... well, maybe some of these are bad practice, but it's unclear that any of them are really things that someone MUST NOT do. And there's certainly nothing today which will prevent them from doing it, or even aid them in deciding whether it's wise. As things stand today, Namespaces are still syntax. Very useful syntax for building rich semantics upon now and in the future. But syntax all the same. ______________________________________ Joe Kesselman / IBM Research
Received on Thursday, 22 June 2000 19:47:19 UTC