[
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
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
|
