Summary, 30 July - 1 August FTF Raliehg

Wednesday 30 July

  Publication plan review:
    Think we have the definitive list of outstanding big issues.
    Shoot for Last Call in November, but might not make that date.
    
  Patterns Task Force:
    RESOLVED to adopt TF Recommendations:
      1. Pattern does not exhaustively define all messages between 
         the named parties.
      2. Patterns define only details relevant to more than one party.
      3. As a result of (2), the participants involved in the pattern 
         must be listed.
    After editors incorporate these changes, proposals for reducing the
    number of patterns will be considered:
      1. TF recommendation: drop request-response and multicast-
         solicit-response patterns, as subsumed by others.
      2. Sanjiva's proposal: drop any pattern not used in a
          normative binding in our spec.
      3. Tom's proposal: drop the "multi" patterns.
    ACTION: Amy to generate proposal for fault rules.
    ACTION: Editors to incorporate the first three recommendations 
            into the draft.

  Removing message:
    RESOLVED (Oracle objecting, expect minority opinion) to 
      1. Remove message per Sanjiva's proposal (@body, @header)
      2. Add hints re: method signatures
      3. Sanjiva's proposed rules for schema writing
    Did NOT agree (Oracle objecting, expect minority opinion) to
      4. Adopting some form of syntactic sugar to better support the 
         RPC use case in the operation construct.
    ISSUE: What does a WSDL processor do when it encounters invalid 
           constructs which it does not care about?


Thursday 31 July
  
  Binding enhancements:
    RESOLVED to change binding/operation/@name from NCName to QName. 
    RESOLVED to make @interface AII optional on binding (and not defined

             on binding/operation). If there is no @interface AII 
             specified, then there MUST NOT be any operation-specific 
             binding details; if an @interface AII is specified, then 
             there MAY be. QName of binding/@interface, when present, 
             MUST match QName of service/@interface.
    ISSUE: Should we rename the binding component?
    ISSUE: The matching process between the QName of binding/@interface,

           when present, and the QName of service/@interface should take

           inheritance into account.
    ISSUE: Can we make do with fewer syntactic constraints?
    RESOLVED to ack the use case for reusable bindings without
addressing 
             it in the spec, because there is a viable solution with 
             external entity, although you wouldn't get binding
operation 
             overloading.
    RESOLVED to eliminate requirement R133.
    RESOLVED NOT to allow in-lining bindings.
    RESOLVED to define default SOAP binding rules:
      1. @body goes into <soap:Body>
      2. Each of @headers goes into <soap:Header>
      3. Drop <wsoap:body>, <wsoap:fault>
      4. Drop <wsoap:header> @type, @namespace, @localname,
@encodingStyle
      5. Add @mustUnderstand (if it isn't there already) and @role.
    ISSUE: Should we move @protocol from <soap:binding> to
<soap:address>?
    ISSUE #2 addendum: Should we define a new binding element for
default 
          rule for wsoap:operation/@soapActionURI, Proposal = 
          interfaceTNS#operation-name
    ISSUE #84: Whether to retain <wsoap:headerFault>.
    ISSUE #85: Fix HTTP binding, since it's now broken.
    ACTION: Philippe to make a proposal for fixing the HTTP binding.



Friday 1 August
  
  Attributes Task Force:
    No consensus on whether to adopt recommendations or not - will take
up
    again in September.
    
  Endpoint references:
    No consensus on approach - will take up again in September.

Received on Wednesday, 6 August 2003 13:17:18 UTC