All this buisiness about namespace URNs...

Kent Sievers ksievers at novell.com
Thu Jun 3 22:27:44 BST 1999


It amuses me to see how far off topic my posting got.  And so quickly.  With everyone fixating on a poorly worded clause of mine, I though I better try again, to see if I could improve on my rambling.  This time, I will pose it as 3 simplified questions:

1) If (as has ben debated on this list) we are worried about URLs because they are not unique and change over time and do not have "ownership" without adding the HTTP protocol, then why don't we invent an ID for name spaces that   IS   globally unique?

2) Are we really that worried about collisions?  If I just used "mynamespace.myproject.Novell.com" as a name space ID, what are the odds that I will ever see any accidental collisions?  And if someone intends to collide with me, then what recourse would I have with any other identifier? 

3) Why isn't our name space identifier two parts:  1) the name spaces name/ID that uniquely identifies it, and 2) the last known, or probable location of the information about the name space.  The advantages of this are: a) I can still uniquely identify the name space no matter where it is moved, b) I can retrieve information about the name space and c) if that information is moved, there may be some hope of searching for it and updating it's location.  Think of it as an ID/URL combination with the URL part optional, but a true URL.

>>> "Michael S. Brothers" <Michael.S.Brothers at EMCIns.Com> 06/03/99 12:26PM >>>

On Wed, 02 Jun 1999 15:08:29 -0400 (EDT) David Megginson 
<david at megginson.com> wrote:

> Kent Sievers writes:
> 
>  > 2) Are we really that worried about collisions?  After all, don't
>  >    I usually know (and approve)  with whom I am exchanging data?
> 
David Megginson reply:

> Not really, especially if you count HTTP transactions as "exchanging
> data", and in the future, I expect that things will get even more
> complicated: e-commerce, in particular, pretty much requires an
> ability for blind information exchange.
> 

This being where an industry-wide standards organization fills the void 
and develops the elements, attributes, etc., for all entities doing 
business in that industry. If such DTD's (x-schema's, whatever) are in 
place, communication within the industry would be seamless. The 
complication arises when trying to exchange data outside the industry.

That's why I fall into the camp of having the namespace designator 
actually point to a document that is retrievable and explains the data 
being sent.

Take Care,

----------------------
Michael S. Brothers
Michael.S.Brothers at EMCIns.com 
515-362-7473
At this point, I don't think that's the best
option.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk 
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)





More information about the Xml-dev mailing list