RE: CR10 : Refined proposal.

Proposals 1-4 use the term "on the Web" which has been asserted to be
well-defined, yet I haven't been able to find a concise definition in
the Web Arch document.  The colloquial meaning it seems to have and the
TAG's intended meaning as relayed by DaveO are quite different, yet both
seem to be quite HTTP-centric.  Without a clear definition, it's
impossible to communicate clearly about why one would choose or not
choose to make a resource available "on the Web" or "over HTTP" or even
"to the general public." 

I thought we were arguing about the tone of the advice we give, rather
than the substance of that advice.  But now I'm not so sure.  I thought
we wanted to point users to the Web Arch document so they can make
informed choices about WS-A features, and thereby avoid known pitfalls.
But it seems there might be a greater underlying agenda - to promote the
Web Arch beyond the scope it declares for itself.  Proposal 1 uses the
term "dictates" in relation to a Best Practice, which seems inaccurate.
It also promotes the "Best Practice" to a "Principle" (e.g. "violates
this principle", which seems to go beyond what Web Arch says.

My text avoids this undefined term and tries to be as specific as
possible about the issues involved, by pointing directly to the Web Arch
document.

I am amenable to adding to my text a direct reference to section 2.2 as
well if you think that's important guidance to communicate, but I'm not
on board with attempts to scare our users away from legitimate use of
our features with text that isn't even supported by the Web Arch
document.

 
> -----Original Message-----
> From: Hugo Haas [mailto:hugo@w3.org]
> Sent: Wednesday, November 23, 2005 7:50 AM
> To: Jonathan Marsh
> Cc: public-ws-addressing@w3.org
> Subject: 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/

Received on Monday, 28 November 2005 20:00:11 UTC