Re: URIs harmful (was RE: Article: Keeping pace with
> --=-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 URLs. 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 brary/x-think11.html
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format