Re: Web Services Addressing 1.0 Core comments

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.  
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 3.2.1 why isn't comparison of [source], [reply endpoint] and [fault
> endpoint] discussed?

Regards,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/