Summary, 3-4 March 2003 WS Description FTF

Monday
  Properties and Features
    Majority interest in continuing to work on this.
    AM proposal:
      Interface Component, Interface Operation Component:
        Add {feature} and {properties} properties, which are 
        sets of Feature Components and Property Components, 
        respectively.
      Binding Component, Binding Operation Component, Port 
        Component:
        Add {properties} property which is a set of Property
        Components.
      Feature Component:
        {name} and {required} properties, which are anyURI 
        and boolean types, respectively.
      Property Component:
        {name} and {value constraint} properties, which are anyURI 
        type and type definition, respectively.
    Syntax Model:
      <wsdl:feature uri="xs:anyURI" required="xs:Boolean"?/>
      <wsdl:property uri="xs:anyURI">
        one of <wsdl:value>content?</wsdl:value>
        or     <wsdl:constraint type="xs:QName"/>
      </wsdl:property>
      <wsdl:value> is a shorcut syntax representating a constraint to 
        a single value.
      Allow <wsdl:feature>* to <interface> and interface <operation>.
      Allow <wsdl:property>* to <interface>, interface <operation>,
        <binding>, binding <operation>, <port>.
    Processing Model:
      Required attribute works like wsdl:required.
      Property constraints are rolled up.

  Proposal to remove binding (collapse binding and interface) rejected.

  7 MEP review (continued to Tuesday)

  QA with Karl Dubost.
    ACTION: Editors will review specification guidelines by 18 March.
    ACTION: Chair and team will review operational guidelines by 18 
            March.
    ACTION: Editors to discuss markup for testable assertions
            in the spec and come back with a strategy.
    ACTION: Jonathan to recruit a QA contact for the WG.
    ACTION: Jonathan to recruit a test contact for the WG.

Tuesday
  MEP review
    ACTION: Editors of the MEPs to record in that document our 
            intention that a CR requirement be that MEPs that
            prove their utility will be left in.  The "utility"
            metric is that a binding (not necessarily from this
            group) which makes use of that MEP be intereroperable
            between two vendors.
    ACTION: Editors MEP to suggest meaningful names for our MEPs
    ACTION: Editors to rename MEP spec to Part 2, old Part 2 
            becomes Part 3.
 
  Clarify type and element
    issue still open, dependent upon proposal to remove message.
 
  Renaming
    portType -> interface
    ACTION: Editors to open an issue on One interface per service
    port -> endpoint
    binding/@type -> binding/@interface
    operation/@mep -> operation/@pattern
    
  Fault naming
    Proposal is obsolete because of MEP-related changes.
    
  Eliminating message
    Topic deferred.

Received on Wednesday, 5 March 2003 15:32:37 UTC