Re: lack of consensus on httpRange-14

Dan Connolly writes:
> > I'm not sure that "lack of consensus" is an appropriate reason to
> > de-prioritize an issue which (at least from my perspective) lies at
> >  the heart of an enormous number of conflicts regarding the proper
> > use of URIs.
> 
> Such as ...?

Well, to put it bluntly, that a lot of people see the "car" model for
URIs as outright ridiculous, and that the "resource is that which is
identified by and identifier which is that which identifies a resource"
gets thoroughly mangled through magical uses of # at the end of the
identifier.

> > While it may be possible to keep those conflicts from spilling
> > directly into a vaguely-worded architecture document, they aren't 
> > going to go away easily.
> > 
> > Might I suggest instead that the TAG close this issue, noting that
> > consensus is not possible, and acknowledge the implications of that
> >  lack of consensus in other work?
> 
> Such as?

(I take it you're asking for implications.)

Such as maybe W3C specs should explicitly consider discuss their
particular usage of URIs and how they interpret them rather than relying
on what appear to be religiously held beliefs about the inherent nature
of URIs.  

If # at the end of an identifier means something to a particular
context, the spec for that context should make that clear, and not rely
on an interpretation of URIs about which there is no consensus.
 
> I think the reason the TAG found it acceptable to defer this issue is
> that in fact it *doesn't* have much impact in other work. We
> spent a lot of time searching for *exactly* what specs/code
> depend on this issue, but we didn't find anything compelling.
> (Some code TimBL has written conflicts with the
> way the dublin core names its properties; that was the biggest
> thing I remember.)

Sadly, the TAG doesn't appear to value the endless hours wasted in
discussion about URIs in nearly every context outside of the URI core
community where they are used that result from this deferred issue.

If the TAG were to declare it simply impossible to reach consensus on
this in the general case, projects using URIs could focus simply on
their specific cases and end the dependence on meaning drawn from a
specification whose meaning is far from clear. 

> Yes, naming is hard work, but such is life.

Naming is always hard work.  Creating useful global naming schemes
appears to be impossibly hard work.

> There's nothing
> special about URIs that makes them magically good nor
> fatally bad names.

Except that their use is regularly mandated by people who appear to
believe that saying "it's a URI" is good and the end of the discussion.

> > That may seem to weaken the general usefulness of URIs, but the 
> > weakness is already present - this would be acknowledging the
> > problem rather than deferring it to future visions of solution.
> 
> which problem?

That there is very little genuine consensus about how URIs actually
work.

-------------
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:1.3.6.1.4.1.6320 is another possibility altogether

Received on Thursday, 3 October 2002 13:17:22 UTC