- From: <Paul.V.Biron@kp.org>
- Date: Tue, 25 Apr 2006 10:28:07 -0700
- To: bob.freund@hitachisoftware.com
- Cc: public-ws-addressing-comments@w3.org
> 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.
Received on Tuesday, 25 April 2006 17:33:02 UTC