|
- Description
-
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?
- Origin
- Paul Biron
(source)
-
Resolution
2006-04-24
accepted by originator
- Agreed to spell out EPR at its first use
|