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?
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.





 

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

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