Re: CR10 : Refined proposal.

* Jonathan Marsh <jmarsh@microsoft.com> [2005-11-21 08:13-0800]
[…]
> Instead I think we should be very explicit about what we're taking
> about, and refer directly to the architecture document and use the
> terminology that document recommends, and the implications of it on ref
> params.
> 
>  
> 
> I also think there are times, for instance bridging a legacy system to
> the internet, where identifying a "resource" using ref params is a
> necessary part of the design, and I'd like to state that clearly as
> well.
> 
>  
> 
> So, I'd like to put forward another alternative for resolving CR10. 
> 
>  
> 
> Proposal 5: The W3C Architecture of the World Wide Web [AoWWW]
> recommends as Best Practice [Section 2.1] the use of URIs to identify
> resources.  Following this best practice precludes the use of abstract
> properties of an EPR other than [destination] to identify resources.  In
> certain circumstances, such a use of additional properties may be
> convenient, beneficial, or even necessary.  However, when building
> systems, the benefits or convenience of identifying a resource using
> reference parameters should be carefully weighed against the benefits of
> identifying a resource solely by URI.

I have also been rereading all proposals for cr10[3] with the addition
of proposal 5.

The issue raised by the TAG[1] is about "using of a single naming
mechanism (URI) for all resources [being] key to the network effects
that underly the extraordinary success of the Web", and proposal 1
says it like it is: one really should be using URIs.

Proposal 5 is building of section 2.1 of the Web architecture
document, which is about the benefits of URIs and points out that
"there are substantial costs to creating a new identification system
that has the same properties as URIs". I believe that this good
practice is targeted to us, creators of a referencing system (EPR)
which may be misused from the POV of the Web architecture, so we need
to be very clear for the users of our specification about the
properties of EPRs.

In our context, in addition to the good practice, I think that the
constraint defined in section 2.2[2] comes into play, as we do have a
URI in an EPR ([address]), but a number of endpoints may be hiding
behind it if other identification parts of an EPR come to play.
Essentially, we need to be clear that not using URIs to doing about
things on the Web is not following the Web architecture and that doing
so makes you on your own.

Similarly, I think that the other proposals (2, 3 and 4) are
down-playing the issue.

So I believe that proposal 1 is really the way to go as I think it
tells things as they are: we are introducing a referencing mechanism
that can be misused from the POV of the Web architecture, and it calls
out what this misuse is.

Regards,

Hugo

  1. http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Oct/0004
  2. http://www.w3.org/TR/2004/REC-webarch-20041215/#id-resources
  3. http://www.w3.org/2002/ws/addr/cr-issues/#cr10
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/