[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Paul has volunteered (was Re: Overloaded URIs must GO!)
Hi James, [Explanation....] Indeed we have here two problems: a) a unique identifier b) a location The former as used in your user example do not need to have a location but a "unique name". The latter obviously a "place where something is stored". We face here the classical URL, URC, URN triad. The best configuration being: a) a name to uniquely identify things (U_niversal R_esource N_ame) b) a set of properties attached to this name (U_niversal R_esource C_haracteristics) c) one of these properties is a location (U_niversal R_esource L_ocation) For people versed in directory services concepts or Grove concepts (recently a copycat of groves: information sets) and more generally in object concepts will recognize the classical problem of classes, instances and properties (property sets being constrained or not by a schema) It seems that for the problem we try to resolve URNs brings better results. Why? a) a URN could used as a unique identifier . i.e. a "name" b) later on, this name could be used to find a "place" where something is stored with a name resolution mechanism. One officially proposed at IETF is the DNS. Other resolution mechanisms could also created and URNs are not solely restricted to DNS name resolution. Ideally, we should evolve toward directory schemas where "names" posses "properties", one or several of these properties could be "locations". For instance, today, LDAP directories elements could be reached with a "LDAP" URL. This URL is a query to the directory service and the URL's schema indicates obviously the LDAP protocol. This URL could be replaced by a URN like in the example below: URL -> LDAP://ldap.itd.umich.edu/c=us into URN -> URN:LDAP:c=us What's missing now is a common name space like actually found with DNS. Originally, the X500 name space was intented for this purpose. Today, we have to specify the target LDAP server in the query URL. In URN we may not have to do so. We would have to just enter, like for DNS name spaces, the nearest LDAP directory in the system configuration (we do that today for DNS). Waht's missing today, is a way for LDAP server to share part of a more global name space. However, several groups are working toward that goal (not always in concert, but we progress). We are slowly, but surely progressing toward the following structure: Objects uniquely identified by names (URN) properties associated to this object (URC) one of these property is a location (URL) Conclusion: it is better to use URNs than URLs. However "names" have to be thought with evolution in minds. So that one day, they could be used to retrieve the properties associated to this name. One of these properties being the location where the document is located. The document may be the complete documentation concerning a particular document architecture. To put in a name a "place" won't assure longevity to a name and it would be funny to observe how incongruous we are because a main selling point for XML is the document longevity :-)). However, it is possible to have unique names wihout having to use URLs like for instance a combinaison of a name and a date (the probablility that two persons have the same name and date is quite low). A unique identifier like for instance RPC UUID. A Creator's name + date + doctype (here again we reduce the probablity of name collision). And I am sure that with the brain power we have here a better schema could be invented than the one I proposed. So hname makes sense as long as we find a good naming schema with low name collision probability. Later on, this "hname" name space (in the URN sense) could be resolved in a "place" where the doc architecture is stored. regards Didier PH Martin mailto:martind@n... http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|