OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Why make namespaces so complicated?

[ Lists Home | Date Index | Thread Index ]

Title: Why make namespaces so complicated?
Understand all these things about public IDs, the point I was trying to make is that at the end of the day both a public ID and a URI are Just A String. URIs can be resolved by indirection just as well as public IDs and public IDs can contain essentially meaningless rubbish. Yes, they can carry some very useful registered information, but (correct me if I'm wrong) that's only really meaningful if you have an ISO registration code of some kind. I am no great authority, but by carrying things like Owner, Class, Version and Language, suddenly they are not really Just A Name anymore, so I can see the "information" conveyed by a public id also going stale. What do I do when I get a document with a public ID whose owner has gone out of business? I can't see it being any more useful to me than a dead URL link.
 
The advantage of URLs, as a particular subset of URIs, is that they have the flexibility to be "self-resolving" as a default behaviour, which is surely quite handy in some circumstances. They don't have to be used on the internet, either.
 
The big advantage of public IDs is that you simply can't do much with them without a resolving mechanism (implicit or explicit), which forces people to think about it a little more. This is surely not a Bad Thing.
 
 
John
 
-----Original Message-----
From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
Sent: 21 February 2002 16:53
To: Anderson, John; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Why make namespaces so complicated?

It does do some things.
 
1.  A public ID is recognized as Just A Name  
 
2.  A public ID has a means to be resolved that is
indirect and extensible.
 
3.  A public ID is clearly an identifier for an owner,
class description, version number, and language.
 
4.  A public ID may use a registry process.  For
those who like that sort of thing, it is possible.  It
does enable those who choose to cooperate a
means.
 
5.  As a level of indirection, it is no worse than
URI to RDDL.   RDDL isn't a standard and
isn't even widely deployed.  Domain control
is fine and you have that.  Others might consider
it worthwhile to control a namespace without
reference to the Internet, DNS, or other systemic
resources.  They may wish to clearly and functionally
state that the owner of the namespace is Owner,
that the Class is Class, that the Version is Version,
that the Language is Language, and so on.  That
is a bit more flexible than the Domain name, actually
for most of the reasons you point out.  It is precisely
because companies go out of business or change
organizations that some prefer public identifiers for
published resources.  It is less corrosive.
 
It is an alternative being explored to avoid reinvention.
That alone may be worth some time invested.  One
should look at the other options.
 
If one insists that a namespace label is only a label
and want to avoid the wink-wink nudge-nudge that
has been the way of the Namespace Rec since
it was published, an alternative is to use the
form of that which is clearly Just A Name, and
the standard from OASIS that provides a means
to resolve that to a location should one so choose.
 
All things on the Internet Are Not The Web. All
things in XML are Not On the Internet.
 
len
-----Original Message-----
From: Anderson, John [mailto:John@Barbadosoft.com]

Using PUBLIC ids instead of URIs/URLs/URCompletelyConfusedByAllTheAvailableAcronyms doesn't solve the problem in the slightest, just moves it somewhere else. Companies will go out of business or change the organization of their publicly available resources. Networks will go down and computers will do things for "no apparent reason"(TM). Hackers will spoof web sites and send viruses instead of whatever it was you really wanted.

If two people choose to use the same string for their namespace URI, tough. It can happen, learn to live with it. If I use a URI that starts with my domain name, I can be fairly sure that no one else can control what is "there"(TM), hackers notwithstanding. If I choose to use someone else's domain name, then I can hardly complain if my applications break because of it.

It is an imperfect world, learn to live with it.

John


_______________________________________________________
John Anderson
CTO BarbadosoftTM
The XML Management Company
+31 (0)20 750 7582 / +31 (0)6 55 347 448 / www.barbadosoft.com


The information transmitted by this e-mail message is intended solely for the use of the person to whom or entity to which it is addressed. The message may contain information that is privileged and confidential.  Disclosure, dissemination, distribution, review, retransmission to, other use of or taking any action in reliance upon this information by anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message.

Although we have taken precautions to minimize the risk of transmitting viruses we nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by viruses.


The information transmitted by this e-mail message is intended solely for the use of the person to whom or entity to which it is addressed. The message may contain information that is privileged and confidential. Disclosure, dissemination, distribution, review, retransmission to, other use of or taking any action in reliance upon this information by anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message.


Although we have taken precautions to minimize the risk of transmitting viruses we nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by viruses.





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS