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

Re: URIs harmful (was RE: Article: Keeping pace with


xmlns pace
[snip a lot of stuff that is mostly good sense but seems tangential to my own 
point]

> Straying back into namespace land, there are several criticisms to make
> of the namespace spec.  Folks could probably live with a URL that
> doesn't point at a real resource, but it's a URL that also can't be
> resolved, normalized, or parsed in any way.

Hmm.  Is there such a thing?


> This points up a larger problem, I think.  In the original URI
> specification, Uniform Resource Identifiers are defined to be the
> superset of Uniform Resource Locators and Uniform Resource Numbers.=20
> Common W3C, and eventually IETF usage, has instead been "URLs carry
> location semantics; URIs don't, even when they look like URLs."  There
> was already a location-algorithm-free means of specifying an identifier:
> urn.  More urn sub-schemes would have had to be created, but even this:
> 
> urn:http://www.w3.org/2001/Schema
> 
> would neatly remove objections to the gutting of URLs.

I really don't see the point of this, or how it would solve any problems.  It 
wouldn't even stop most mail agents from highlighting namespace decls as if 
they were hyperlinks, to give a whimsical example.


> And this would
> have been much nicer, for namespaces:
> 
> urn:xmlns:[dns][path]
> 
> The latter retains the ability to administratively impose uniqueness on
> URIs, without being less readable than common (and connotatively
> locatable) URLs.

Yes.  People have argued for an xmlns URN namespace, and I agree that this 
would be nice.


> I'm still really irritated with the recent specs and RFCs that use the
> term "URI" in preference to "URL," when it's perfectly clear that they
> mean something that has location semantics.

Like what?  On a practical level, there is no base URI resolution mechanism I 
know of for any URN namespace (OIDs don't have absolute/relative aspects, do 
they?).  Therefore it would seem XML Base should just say "URL" and be done 
with it.  Bu there is nothing to prevent future work from adding base 
resolution semantics to certain URN namespaces.


> What's the value in
> blurring the distinction between the two?  Why should anyone be happy to
> see suggestions that URLs be created 404 from birth?  Why shouldn't
> folks demand that, if a URI is being used for identification only, that
> it not somehow indicate that fact within the URI?

This might be a good practice, but I do *not* want any spec to mandate it.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Track chair, XML/Web Services One Boston: http://www.xmlconference.com/
The many heads of XML modeling - http://adtmag.com/article.asp?id=6393
Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li
brary/x-think11.html



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.