Re: Web Services Addressing 1.0 Core comments

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Web Services Addressing 1.0 Core comments

Hugo Haas
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:[hidden email] - http://www.w3.org/People/Hugo/

signature.asc (318 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Web Services Addressing 1.0 Core comments

David Hull
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 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

  

Reply | Threaded
Open this post in threaded view
|

Re: Web Services Addressing 1.0 Core comments

Paul.V.Biron

David, thanx for the quick response.

>> 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.


I understand this rationale...but in that case I think it would be good to put something in the "Notational Conventions" section explaining this...so that other readers don't have to wonder.

>> 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.

> 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".

By "capitalized appropriately" I meant that they should be ALL CAPS when they have conformance strength and not caps when they don't.  I was rushed when doing my review and wasn't sure in what sense these were being used in this context.  Upon further reading, I think both occurances of 'may' in this paragraph do NOT have conformance implications for implementors of THIS spec...so they are OK not capitalized.  I still request that the editors do a double-check to make sure that those that do have implications for implementors of THIS spec are ALL CAPS.

> 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 around just this issue, but for
> better or worse, [destination] is an IRI.


I'm glad I'm not to only one to feel that there is something wrong.

> 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.

I think it is fine to have it in 3.4...I guess I was just asking for a "forward pointer" in 3.2.

> 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.


It would help me (and I think others) if you included something similar to the above paragraph so that readers don't have to stop and ask "hey, they talk about comparison of *those*, why aren't they talking about comparision of *these*?"

Again, all of HL7's comments are basically editorial in nature (wsa:To as an EPR is a little stronger than editoral :-) and so any resolution you come up with is fine.  We are looking forward to WS-Addr becoming a Rec because we have are developing a standard that relies on it and we can't progress that one until WS-Addr becomes a Rec.

pvb
Reply | Threaded
Open this post in threaded view
|

Re: Web Services Addressing 1.0 Core comments

Bob Freund-Hitachi
In reply to this post by Hugo Haas
Dear Paul,
Thank you for taking the time to review and comment on the specification.
 
The Web Services working group met on April 24 2006 to consider your comments against the WS-Addressing Core specification and in this email is responding to you with the decisions reached in that meeting.
 
We hope that these decisions are acceptable to you.  If you are satisfied, please respond with your consent.
 
Thanks
-bob
 
1. The EPR abbrev is used without first defining it
> 
The working group agrees that this is awkward and has spelled out endpoint reference at its first use.
 
> 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 :-(
 
Perhaps so, but it is not.
 
> 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.  
 
Several reviewers prefer the current order, some the other.  The working group decided to leave the current order unchanged.
 
> 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.
 
The working group has reviewed the text and feels that the current capitalization is consistent with our intent as well as the guidelines specified in RFC 2119.
 
> 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?
 
The working group feels that references are not normative and thus it is acceptable in this case.
 
> 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.
 
We acknowledge that the order is not specified in the abstract, but we have so far had no difficulty on this point in implementations.  We do not foresee what this change may fix or break, so we prefer to leave the current text as-is at this point.
 
> 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.
 
This issue has been heavily discussed in the past and the working group was narrowly divided.  The issue will not be re-visited since the arguments one way or the other remain the same as they were at the point the issue was decided.  That prior decision resulted in the filing of a formal objection <http://lists.w3.org/Archives/Public/public-ws-addressing/2005May/0047>.  Notwithstanding this objection, the working group has decided to take no further action.
 
> 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.
 
We agree that it may have been nice if the names matched, however, it is late in the game for this degree of change to be assimilated.
 
> 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.
 
The further exposition on these properties was included in underlying binding specifications which factoring allows appropriate treatment based on the characteristics of the underlying protocol.  When using these bindings of MAPs to XML, they are explicitly defaulted to anonymous.  The group decided to leave the current text unchanged.
 
> 3.2.1 why isn't comparison of [source], [reply endpoint] and [fault
> endpoint] discussed?
 
This 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.
 

 

Reply | Threaded
Open this post in threaded view
|

Re: Web Services Addressing 1.0 Core comments

Paul.V.Biron

> We hope that these decisions are acceptable to you.  If you are
> satisfied, please respond with your consent.

yes...I am satisfied with these responses. A few comments below.

pvb
> > 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?
>
> The working group feels that references are not normative and thus
> it is acceptable in this case.

So you are saying that the sentence "Web Services Addressing 1.0 - WSDL
Binding" describes the mechanisms of Association" has no normative
force...and there may be other valid ways of associating an [action] with
a WSDL.  If so, then this is OK.

> > 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.
>
> This issue has been heavily discussed in the past and the working
> group was narrowly divided...That prior decision resulted in
> the filing of a formal objection.

I'm just glad to know that I'm not the only one to find the current
situation strange...as they say, if it walks like an EPR and quacks like
an EPR...then it is an EPR :-)

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

I understand the "thorny issues".  I think it would be helpful to many
readers for you to provide a paragraph or so explaining why you aren't
describing the comparison of [source], etc...but like I said, I'm
satisfied with this response and won't push it if you choose not to add
the explanation of why you aren't describing the other comparisons.