RE: CR10 : Refined proposal.

You seem to think the term "Best Practice" as used in AoWWW is a weak
term.  Perhaps it's not what they really meant when writing that
document?  That's strange, but if you don't think that term correctly
conveys the intent, I'm willing to abstract it out as well.

It also seems the more we can encourage people to actually read AoWWW
the better, so they understand those benefits and can actually make use
of them.  Further encouragement to read section 2 might help here.

Proposal 5a:  The W3C Architecture of the World Wide Web [AoWWW]
recommends [Section 2.1] the use of URIs to identify resources.  Using
abstract properties of an EPR other than [destination] to identify
resources is contrary to this recommendation.  In certain circumstances,
such a use of additional properties may be convenient or beneficial;
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 as
explained in [Section 2. Identification] of the Web Architecture.

One more option shouldn't make the chadding any more difficult...

> -----Original Message-----
> From: Hugo Haas [mailto:hugo@w3.org]
> Sent: Friday, December 02, 2005 3:22 PM
> To: Jonathan Marsh
> Cc: public-ws-addressing@w3.org
> Subject: Re: CR10 : Refined proposal.
> 
> * Jonathan Marsh <jmarsh@microsoft.com> [2005-11-28 11:59-0800]
> > 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 believe that "on the Web" means, at least here, referenceable by a
> URI, as this is what the note is about.
> 
> > 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.
> 
> I too think that we are arguing about the tone of the advice, and I
> believe that your latest proposal is understating the importance of
> URIs in the Web architecture.
> 
> I disagree with qualifying using URIs instead of URIs+QNames as
> identifiers as a best practice.
> 
> Section 2 states:
> 
>     URIs are a cornerstone of Web architecture, providing
>     identification that is common across the Web.
> 
> and then dictates the following "Principle" about using them:
> 
>      Global naming leads to global network effects.
> 
> I believe that section 2.1 points out that, as a good practice, you
> will benefit from identifying stuff, and, as you're on the Web, you
> should do it with URIs.
> 
> Section 2.1 of the Web Architecture document is pretty clear that one
> should avoid using another identification mechanism if you thought
> that you should identify something:
> 
>     There are substantial costs to creating a new identification
>     system that has the same properties as URIs.
> 
> > 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.
> 
> I am uncomfortable suggesting changes to your proposal 5 as I believe
> that it is not going in the right direction.
> 
> As "on the Web" seems to be an issue, I can proposed instead a very
> minor change to proposal 1:
> 
>      Proposal 1: Add note: Web Architecture dictates that resources
>   should be identified with URIs.  Thus, use of the abstract
properties
>   of an EPR other than wsa:address to identify resources is contrary
to
>   Web Architecture.  In certain circumstances, use of such additional
>   properties may be convenient or beneficial, perhaps due to the
>   availability of QName-based tools.  When building systems that
>   violate this principle, care must be taken to weigh the tradeoffs
>   inherent in deploying resources that are not on the Web.
> 
> which is proposal 1a:
> 
>      Proposal 1a: Add note: Web Architecture dictates that resources
>   should be identified with URIs.  Thus, use of the abstract
properties
>   of an EPR other than wsa:address to identify resources is contrary
to
>   Web Architecture.  In certain circumstances, use of such additional
>   properties may be convenient or beneficial, perhaps due to the
>   availability of QName-based tools.  When building systems that
>   violate this principle, care must be taken to weigh the tradeoffs
>   inherent in deploying resources that are not identified by URIs (see
>   section 2.1 Benefits of URIs of AoWWW).
> 
> Proposal 1a is proposal 1 with "on the Web" replaced by "that are not
> identified by URIs", and added a link to section 2.1 which is a
> pointer to help weighing those trade-offs which is something you seem
> to value.
> 
> Cheers,
> 
> Hugo
> 
> --
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Monday, 5 December 2005 20:38:50 UTC