Re: Web Services Addressing 1.0 Core comments

Paul,

Inline below is my understanding of why some of these things are the way
they are.  I'm speaking for myself, not the group, so naturally any
errors or misrepresentations are mine.

Hugo Haas wrote:

>I am sending those comments on behalf of Paul Biron. Bob, can we
>please have those on Monday's agenda?
>
>  
>
>>1. The EPR abbrev is used without first defining it
>>
>>1.1 It's too bad that XML Schema Component Designators
>>[http://www.w3.org/TR/xmlschema-ref/] isn't farther along, because then
>>you wouldn't have had to invent your own syntax to do what they do :-(
>>
>>2 Is it just me, or doesn't this section seem out of place, coming before
>>section 3?  I would like the spec would read better with the current
>>section 2 & 3 reversed in order.  
>>    
>>
Section 3 depends on terms defined in section 2, but not vice versa. 
Take your pick whether you like bottom-up or top-down.  For better or
worse WSA is bottom-up in this respect.

>>2.1 [address] is defined as an IRI but the description contains "...this
>>URI is used...".  Shouldn't that says "...this IRI is used...]?  This
>>happens in a few other places.  The editors should carefully check all
>>uses of URI to insure that they shouldn't actually be IRI.
>>    
>>
This usage is deliberate.  If something meets the tighter constraints of
URI, we say "URI", otherwise we say "IRI".  So for example [address] is
an IRI, but the anonymous address in particular is a URI and we say so. 
It would also be correct to say " ... this IRI is used ..." but we
discussed the issue and opted for the present wording.

>>3 "The contract between the interacting parties may specify that multiple
>>or even a variable number of replies be delivered" should be "The contract
>>between the interacting parties MAY specify that multiple or even a
>>variable number of replies be delivered."  The editors should check all
>>uses of "conformance verbs", to make sure they are capitalized
>>appropriately.
>>    
>>
Consistent capitalization is good style, and we should fix this where
necessary, but RFC 2119 doesn't strictly require it ("These words are
often capitalized," it specifically says at the top)  The more important
question is whether we are using these words in their proper RFC 2119
senses, since we're implying this regardless of capitalization.  I would
say that this particular case is mostly OK, except that we're talking
about definitions of MEPs and not implementations by vendors.

In other words, the classic RFC 2119 MAY means "One vendor may choose to
include the item because a particular marketplace requires it or because
the vendor feels that it enhances the product while another vendor may
omit the same item."  Here we're saying that different interactions may
define various rules and the presence of "ReplyTo" doesn't necessarily
mandate use of a particular definition of "Request-Response".

One usual way around this is to say something like "can" instead of
"may".  Another might be to clearly mark the whole section non-normative.

>>3.1 (and elsewhere) References are made to the WS-A WSDL Binding spec,
>>although that hasn't even reached CR yet...is that kosher according to the
>>process?  I thought that a spec could only reference another spec if it was
>>no more than 1 step back in the process.  Has that changed?
>>
>>3.1 [relationship] In the abstract definitions it is unclear whether the
>>relationship type is the 1st or 2nd member of the pair.  It is possible
>>that it doesn't really matter to define that at the abstract level...but
>>it would appear to be necessary.
>>
>>3.1 [reference params] I'm sure there's a good reason but why isn't
>>[destination] and EPR?  The presence of [ref params] (and it's description
>>as applying to [destination] )would seem to indicate that [dest] really is
>>an EPR and not "just" an IRI.  Is the current model because of difficulty
>>binding "to" EPRs to common transports?  I realize it is VERY late in the
>>process to change something this fundimental but it has always seemed odd
>>to me...sorry for not saying anything sooner.
>>    
>>
Heh.  There is a formal objection
<http://lists.w3.org/Archives/Public/public-ws-addressing/2005May/0047>
around just this issue, but for better or worse, [destination] is an IRI.

>>3.2 minor nit: why do the abstract properties and infoset reps have
>>different names?  Wouldn't it be less confusing for them to have the same
>>name?  E.g., destination and wsa:To, source and wsa:From.  As written, I
>>always have to perform a mental mapping between them.
>>
>>3.2  section 3.4 describes the default for wsa:FaultTo as being
>>wsa:ReplyTo..and if wsa:ReplyTo is empty then it's a free-for-all. 
>>Shouldn't this behavior be stated here?  since the defaults of all the
>>other properties are described here.
>>    
>>
Again, this is deliberate (originally the description /was/ in section
3.2).  This section defines the semantics of [reply endpoint] and [fault
endpoint] /in the context of request-response/.  Other patterns may
define other semantics.  These shouldn't be gratuitously different from
what we give here, but they may have to be different in various ways. 
Perhaps there is a good reason [fault endpoint] shouldn't default to
[reply endpoint], but both designations otherwise make sense. We did not
want to prohibit that.

>>3.2.1 why isn't comparison of [source], [reply endpoint] and [fault
>>endpoint] discussed?
>>    
>>
This, too, is deliberate.  There are thorny issues involved in defining
the context within which a particular comparison is meaningful. 
Byte-for-byte identical EPRs may mean different things depending on
context, and completely different-looking EPRs may mean the same thing. 
Rather than try to define what an EPR "means", we define what you can do
with it.

>
>Regards,
>
>Hugo
>
>  
>