Re: theory and practice (Re: URIs for Physical Items)

At 10:26 AM 10/29/00 +0000, Graham Klyne wrote:
>It may not be perfect, but I found the following enormously helpful in 
>coming to some level of understanding about the wider role of URIs...
>
>   http://www.w3.org/DesignIssues/Axioms.html
>   http://www.w3.org/DesignIssues/Fragment.html
>
>and the following helps to show how the ideas can be applied to 
>applications that are not necessarily the web-as-we-understand-it-today.
>
>   http://www.w3.org/DesignIssues/Webize.html

Actually, I found all of those documents deeply contentious.  Their being
labeled 'personal view only' doesn't exactly enhance their position as
foundations.

>... I think the problem is that any particular piece of infrastructure can 
>apply only to some part of the uses to which URIs may be put.  (I'll 
>suggest that even DDDS is not a universal solution for every imaginable URI.)

Agreed - but there needs to be a more useful and more approachable route to
URI processing than tracking down RFCs, if in fact they were published.
'Use Google' isn't exactly the kind of answer I want to give people trying
to deal with particular URIs and URI schemes.

>>While I value the chaotic approach, I haven't seen any attempt to balance
>>that chaos with infrastructure (or even documentation) that developers can
>>walk up to and figure out.  'itty bitty pieces' backed up with theory that
>>doesn't play well outside of a core community doesn't seem like a recipe
>>for success to me.
>
>I think it is the role of _application_ designers to put together the 
>pieces to create a complete specification that gives developers all the 
>information they need to build an application.  It is in the nature of 
>component pieces that they are not of themselves complete applications.

You've said this repeatedly, and I continue to disagree.  Maybe it's just
that I'm more comfortable with XML's balance between application designers
and general processing, but I find 'URI processing' to be an oxymoron if
not downright incomprehensible.

>As for not playing well outside a core community ... yes, you have a 
>point.  Personally, I think the main problem here is one of effective 
>communication, but also to a lesser extent lack of absolute 
>clarity/agreement _within_ the core community.  I predict that the next 
>year or so will see a wider view of URI usage becoming more widely 
>accepted.  The DDDS work may be one vehicle for this.

It's worse than _lack_ of communication - it's that what communication
there is has in fact contributed to a lot of people seeing URIs as strange
creatures best left to obscure specifications and a small group of loving
supporters.

>>Too many developers don't have control over the documents they have to
>>process. In that situation, some kind of supporting infrastructure would be
>>very helpful, and would remove a lot of the fear and loathing currently
>>involved with URIs.
>
>[Noting your later comment that you meant control over _URIs_]
>
>For applications where this matters, it is important that the application 
>specify or characterize the allowable URI schemes.  But such specification 
>is not properly part of the specification of URIs.

I would argue that it is, and that the balance between application-specific
URI functionality and generic URI functionality is currently off.

>But there are applications where this does not matter -- where URIs are 
>being used simply as a way to label (identify) some resource (e.g. as you 
>have argued the case for XML namespaces, or in RDF graphs of abstract 
>knowledge).  In such cases, the URI scheme serves to identify rules of 
>allocation/definition of URIs without necessarily saying anything about how 
>such names are processed.

RFC 2396 doesn't even provide adequate labelling tools - there's no single
way to compare these labels without sifting through scheme-specific documents.

>I would suggest that the power of URIs is that it allows applications to be 
>defined using some specific form of names, yet leaves open a natural path 
>for later extension to incorporate other, as yet unknown, kinds of 
>identification.  I sense that your unease is with this open-ended and hence 
>unspecifiable aspect of URI usage.

Unspecifiable?  Try uncomparable.  (Not incomparable as in wonderful,
either.) Try unprocessable.  Try unpredictable.  Try underspecified. Not a
pretty situation.

>I grant that, in the final analysis, most applications must work with some 
>specified set of URIs having properties appropriate to the task 
>performed.  Interoperability specifications need to indicate the allowable 
>set.  But the universal structure of URIs allows that new ideas can be 
>incorporated into new versions of applications without breaking the core 
>application architectures.

The universal structure of URIs provides new clothes for the emperor.  So
thin, so fine, so light!  But a lot of people think the emperor is
genuinely naked.

XML provides universal extensible structures - but it provides much
stronger ground rules for processing them, a real foundation.  URIs provide
some nice ideas and a syntax, not much more.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

Received on Sunday, 29 October 2000 18:42:14 UTC