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] URIs harmful (was RE: [xml-dev] Article: Keeping pace with

[ Lists Home | Date Index | Thread Index ]

> --=-Du4tboh4H+82AcmX1QAO
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> Hmmm ...
> On Fri, 2002-07-19 at 22:03, Uche Ogbuji wrote:
> > Simon wrote:
> > > Namespaces are probably the worst place where this pollyanna attitude
> > > has smacked XML, but their progeny, QNames, offer their own set of
> > > problems.
> [snip]
> > The harm of URIs is rather well contained when we apply to them the same=20
> > attitude the loosely-coupled clique applies to XML itself.  Let each pers=
> on=20
> > use them as he pleases and don't try any overarching design of URIs.  The=
>  key=20
> > is in loose coupling between signifier and signified, and between the age=
> nt=20
> > granting the name and the agent using the name.  Tight coupling between=20
> > signifier and signified is one of my quarrels with Topic Maps.  Tight cou=
> pling=20
> > between the granter and the receiver of the name is one of the reasons I'=
> d=20
> > rather the W3C and others didn't address URI issues by fiat, even to squa=
> sh=20
> > 3000-message threads.
> Err, yes and no, I think.
> Sending "URL" off to "URI-land," in which nothing can be known about
> what's inside the box, leads to unpleasant results not only due to the
> confusion over dereferencing, but due to the change in semantic.
> A URI used as a namespace is officially a string, and you can only do
> string comparisons.  Case is significant.

[SNIP many concerns with URI syntax/semantics that I am all too painfully 
aware of]

> The namespaces rec specifically states that URI reference identity
> requires character-by-character identity, and it appears that there has
> been discussion within the TAG about the potential difficulties of doing
> anything more complex.  There is clearly a great deal of complexity ...
> but it gets easier and easier to challenge the claim that "this is a URI
> reference" the further that the namespace string's semantic drifts from
> the semantic of a URI.  A namespace name, in fact, is a thing that has
> URI syntax.  Only.  It isn't a URI, or a URI reference, it is a
> namespace name, which is defined to have URI syntax.  If I happen to
> have a URL object off over here that's intended for use (location of a
> resource, that is), it just isn't safe for me to compare its string form
> with a namespace name.
> Which is to say, I don't think it's really an issue of coupling, but an
> issue of ambiguity, as Simon (and Len) originally suggested.  Using a
> form (syntax) that carries extremely heavy connotations of an associated
> semantic, and violating that semantic (here I'm not speaking of the
> location algorithm, but of case-sensitivity, encoding, and resolution
> only, mind), is just guaranteed to produce confusion.  Witness the
> 3000-message thread that Just Won't Die (and TBL reopened it with a
> suggestion that "relative URIs", an utterly *meaningless* concept when
> namespace names have been divorced from URI semantic (say "relative
> string" and "absolute string" and see what meaning you can discover),
> are not all that bad after all ... *sigh*).

I don't think we're arguing the same point.  I agree entirely with both Len 
and Simon about the ambiguity that emerges when namespaces adopt the syntax 
and not the semantics of URI.

My argument is more to simon's assertion that URIs *in general* are flawed.  
Simon mentioned that URIs are a sign of trouble for him in any spec.  I can 
understand that position taken, as it is, after looking at the mess that lies 
across treatment of URIs in W3C land, but I think that to fundamentally blame 
URIs misses the mark.

I agree with the big thinkers in the IETF that URLs are as much a n identifier 
as a locator.  I could argue it culturally: that most users of URLs see them 
as names and not locations.  Remember how few Web users *ever* actually deal 
with a URL that extends beyond the domain name of some organization they know. 
 I can also argue it technically (though philosophy intrudes) by pointing out 
that URL features such as redirects and entities only make sense when the URL 
is considered a resource identifier.  However, I know that others might 
disagree, and I'm not willing to go into a long thread about the essence of 

However, if it is at least reasonable to look at URLs as identifiers, then I 
think that all the problems you, Len and Simon state are unfortunate, but 
merely the symptoms of the choices of one arbiter of URI usage (the W3C), and 
not a symptom of fundamental uselessness of URIs themselves.  If we'd gone 
with FPIs instead, we'd have the same problems in variant forms.

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


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

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