[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Registered Namespace prefixes

  • To: "'Gavin Thomas Nicol'" <gtn@r...>, XML Dev <xml-dev@l...>
  • Subject: RE: Registered Namespace prefixes
  • From: Jeff Lowery <Jeff.Lowery@c...>
  • Date: Thu, 6 Mar 2003 17:54:00 -0800

prefix re
Gavin: 
> Jeff:
> > I don't know how one could assign ownership of a nonconflicting,
> > short-sequence namespace identifier through any other 
> mechanism than a
> > registry.
> 
> My question is: why do you need to? 
> I always hear that 
> rationale that "we need 
> to mix and match arbitrary tag sets", but that only matters 
> if you do it 
> blindly, and somehow have a magical dispatch table keyed off 
> the prefix or 
> the URI. That's generally not the case, and generally not 
> open-ended even if 
> it exists (though you *could* do it using a registry).

I agree.  I'm not on about tag soup or namespace-aware processing.  What I
want to do is:

1) eliminate the need to resolve namespace prefixes
	-- simplifies tools
	-- reduces mistakes
	-- avoids overhead 

2) eliminates any need to preserve prefix/nsID pairs during roundtrip
processing of documents

"But a registry is overhead!" I hear you shouting.   True, but namespace
prefix resolution mechanisms in tools are also overhead.  

Now, I'm not going to say that the way namespaces are now is a damning
burden to bear, but if something's going to be foundational, then any
complexity at the base level risks being propagated upward through each
layer resting on top. 

 
> If that's not true, you will have some form of 
> convention/agreement in place 
> that let's you know what to expect.... you'll know what a 
> name:space is, and 
> an html:p. In that case, the registry is largely superfluous, 
> because if you 
> and I have a convention to use foo: prefixes in our data 
> interchange, why 
> should we care if some other party uses it? 

First of all, basing any logic on ns prefixes (as they exist now) is a risky
deal, convention or no.

Second of all, we do care (most of us anyway) about the associative
integrity of a namespace id.  Think not?  Most namespace ids are based on
URLs with domain names at their root.  If you're running around adding
associations to namespace URLs starting with "http://www.microsoft.com", I
think you had better hope your associations don't become so prevalent that a
certains company's attorneys get wind of it.  Nothing (but common sense)
prevents you from polluting the associative space of namespace ids rooted at
MS's web address, at least until you attain a certain level of notoriety.


> If we expect to 
> deal with their 
> data at some point, we might, but we might at that point also 
> negotiate the 
> use of a different prefix.

Again, even with convention, doing this with 'unregistered' prefixes is
risky business, IMO.  But yes, it can be done.

 
> For vocabularies that people *do* care enough about to 
> standardize, there are 
> already registration vehicles in place.

Like OASIS?   I suppose.  

> 
> > Just to hammer this nail one more time: there's no need to 
> 'consult' the
> > registry.
> 
> Your registry is 
> really just for 
> humans to use? 

I think that's a good way to put it, although I wouldn't rule out things
like a basic lookup/dump web service.

>That might help people who write standards.

Merely recommending, my friend. Merely recommending.

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.