[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!)

  • From: "Didier PH Martin" <martind@n...>
  • To: "'XML Dev'" <xml-dev@i...>
  • Date: Sun, 30 May 1999 09:44:00 -0400

ldap urn
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.