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/