[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: URI concerns continue
I agree the URI's are built on quicksand for the most part, once you leave the shaky ground provided by URLs, which have their own problems. The whole concept of "authorities" presumes an exactitude in the world that simply doesn't exist in any real sense. Even URL's can be (and have been) subverted. The authority of URL's depends entirely on the goodwill and skill of all (or almost all) participants in the DNS scheme of things. It's a lot like driving. Laws don't make driving safe any more than pinted lines on the road make it so; the totality of the safe and skillful behaviors of almost all of the other drivers on the road makes it a relatively safe activity for most of us. While it may be true that having a naming authority "guarantees" uniqueness, many of the examples chosen leave one with no reasonable way to determine that fact or to find out what a resource is in reality. ISBN's, for example, used to identify certain books in international trade, cannot be turned into book names or even verified without subscribing to the Bowker service which originated them. In addition, the naming authority for these numbers is distributed, with relegation going to countries and firms whose implementation of the rules may be different from those in the USA and whose filing system consists of a cluttered cardboard box in the corner of an office. There is, in fact, no possible way to do a "simple database lookup" of a random ISBN number. And of course, many books have no ISBN number at all, so it's quite possible to have a need to describe a particular book without an ISBN number available to guarantee uniqueness. There are no naming schemes available which cover every book, and many books are covered by several. Any particular scheme one chooses will leave others out in the cold for the simple reason that there is not now and never will be a universal encyclopedia of human knowledge.. Pablo Picasso is an easy example, the ultimate naming authority for his paintings, so URN:Picasso:Guernica would be at least theoretically valid, but doing a lookup in the Picasso database is quite plainly difficult. This is why experts on art make big bucks deciding whether a painting belongs in the Picasso database or not. Disambiguation is precisely what they do but your average site is probably not going to want to pay their authentication fees in order to disambiguate every odd reference to this particular painting. Most of us take it on faith that the painting the guide points to as Guernica by Picasso is in fact that same, even if it's hanging in Fred's High-Class Art Museum and Gallery of Little Rock, Arkansas. From the proliferation of silly ideas on the Web, it's quite clear that faith and gullibility will play an important part in the sum total of information one sees on the Internet. Most of the bodies proposed as naming authorities for URI's are subscription services and either refuse to allow random requests gratis or have no machine-readable form at all. Has anyone addressed the issue of what earthly good a naming authority is if it exists only in paper form and/or only by subscription? While this might be seen as an issue of choosing wisely, in many cases the "unwise" choice is the only realistic choice. Are users going to respond well to a browser that says, in effect, "Please deposit US$25 to continue?" The reason URL's are so popular as identifiers, despite their uncertainty and lack of persistence, is that DNS guarantees that they are free for anyone to use. The minute you step away from the Commons that URL's represent, however, you run into fences, No Trespassing signs, and toll roads. It's rather difficult to legally get anywhere without unlimited funds. So many of the naive URI schemes one sees as exemplary of non-URL instances of URI's really only cohere or seem plausible when one doesn't know very much about the problem space. In the absence of certainty, or at least certainty we can all afford, most of us will be stumbling around with half-baked ideas and guesses on the Internet, just as we do in real life. So URI's are being used for all sorts of purposes, including setting internal program switches, which have nothing to do with the specification which rather loosely defines them. And if a manufacturer, say Microsoft, takes over the meaning of a URI belonging to another body, say W3C, in such a way that the original owner has no further control of it, in what sense is the original authority still authorized? Embrace and extend would seem a misnomer, in this instance; more correct might be embrace and digest. At 07:08 AM 7/11/00, Simon St.Laurent wrote: >At 09:41 AM 7/11/00 -0400, Michael Mealling wrote: > >Just because you have an incorrect perception of the use of something > >doesn't mean that everyone else is wrong. URIs identify Resources > >in the abstract. That is their definition. You don't get to > >redefine that simply because your experience is limited to the > >http scheme and some counter-productive, SGML-ish, bifurcation of > >public vs system identifiers. > >Thanks, Michael. It's always nice to be told that I'm wrong. Of course, >since I'm calling URIs a quicksand foundation, I suppose I should expect >some irritated responses. > >My experience is not limited to the http scheme, I'm afraid, though I think >I may have a better understanding of the public expectations surrounding >that scheme than some wise fellows. > > >Any identifier can use be used to retrieve something. Its called a > >database lookup. You can do lots of things with an identifier: use it > >as a key to a database, use it to disambiguate something are two of the > >most important. Those two functions are not mutally exclusive or > >incompatible, > >They are, however, severely underspecified, and the current uses of URIs in >XML specifications set no such expectations for those features. As we've >found, even simple comparison is lacking in RFC 2396. > > >> Does your placement of schemas at namespace URIs make you a hijacker? I'd > >> say it very well might. > > > >If he has the assignment authority over that identifier used in that >namespace > >then no he isn't.... > >He's making additional claims about the usage of those URIs which are not >in the specification. If I was in a bad mood, I'd call it 'embrace and >extend'. > > >If you choose to name your namespace badly or in such a way as to make > >it difficult for someone to learn about your namespace then that's your > >problem (or your intent). Its not the problem of xml namespaces or URIs.... > >The specifications leave open an astounding number of ways to use these >things badly. It's the problem of the namespace specification's failure to >limit and define the tools provided by RFC 2396, which itself does very >little defining. > > >> >In some cases, the abstraction is a static entity body. > >> >http://www.ietf.org/rfc/rfc2396.txt is such an example. > >> >But this is not the general rule -- it is a special case. > >> > >> It's not even the general rule that there is an entity body. In fact, I'm > >> not sure that there is a general rule beyond the existence of the syntax. > > > >The general rule is defined based on the scheme. But you know that > >all schemes identify some Resource. Its up to you to pick a URI that > >makes sense for what you're trying to do. If you pick badly then > >its your fault. Don't blame the infrastructure for giving you the > >freedom to cause problems for yourself... > >I'd suggest that the builders of infrastructure would be wise to stop >building on quicksand and then blaming the unlucky victims. > > >> This doesn't seem like an appropriate foundation for the kinds of > >> non-retrieval tasks URIs are being asked to do in various (namespace, > >> schema, XLink) XML contexts. > > > >Why not? You just want a name right? urn:oid:1.3.6.1.4.1.5 sounds > >like it covers the bases to me... > >I agree. Perhaps Namespaces in XML should have used URNs only. > >Simon St.Laurent >XML Elements of Style / XML: A Primer, 2nd Ed. >http://www.simonstl.com - XML essays and books
|
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
|