Web Services Addressing Proposed Recommendation Issues List

$Date: 2006/04/26 23:38:51 $

$Revision: 1.6 $

Statistics

core soap wsdl testsuite schema all total
open 0 0 0 0 0 0 0
proposed 0 0 0 0 0 0 0
closed 1 0 0 1 0 1 3
duplicate 0 0 0 0 0 0 0
dropped 0 0 0 0 0 0 0
total 1 0 0 1 0 1 3

Open Issues Summary

id owner title target type

Closed Issues Summary

id owner title target type
pr1 mU fault one way test testsuite
pr2 HTTP Web Method Not Specified in test documentation or specifications all
pr3 Comments on Core and Soap Proposed Recs core editorial

Detailed Listing

pr1 mU fault one way test testsuite - - closed
Description
 I took a look at the testsuite [1], and did not find a test where a
            FaultTo is set, a mU fault happen, and we are in the one way case (or 
            should I say the ROR case).
            Did I miss it? or is such addition planned?
            Thanks,
            
            [1] http://www.w3.org/2002/ws/addr/testsuite/
         
Origin
Yves Lafon (source)
Resolution 2006-04-24
Close with no further action
pr2 HTTP Web Method Not Specified in test documentation or specifications all - - closed
Description
         For the group's interop tests held in January, I wonder if somebody
         could tell me what HTTP Request-URI was used in the messages?  I've
         been unable to determine that from the testsuite site[1], nor, as
         mentioned in the TAG discussions, does the WS-Addressing spec say
         anything implicitly or explicitly about it.  Have I overlooked
         something?
         
         Thanks.
         
         [1] http://www.w3.org/2002/ws/addr/testsuite/
      
Origin
Mark Baker (source)
Resolution 2006-04-24
Close with no further action
pr3 Comments on Core and Soap Proposed Recs core - editorial - closed
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