W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2004

Minutes: 28 Jan 2004 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 4 Feb 2004 09:49:02 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2027A6BC4@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Group
Minutes, FTF meeting 28 Jan 2004
Bedford, hosted by Sonic.

irc: http://www.w3.org/2004/01/28-ws-desc-irc

 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Tom Jordahl            Macromedia
 Philippe Le Hégaret    W3C
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Adi Sakala             IONA Technologies
 Jerry Thrasher         Lexmark
 William Vambenepe      Hewlett-Packard
 Umit Yalcinalp         Oracle

 Allen Brookes          Rogue Wave Software
 Amelia Lewis           TIBCO
 Kevin Canyang Liu      SAP
 Jean-Jacques Moreau    Canon
 Sanjiva Weerawarana    IBM
 Prasad Yendluri        webMethods, Inc.

 David Booth            W3C
 Youenn Fablet          Canon
 Jacek Kopecky          Systinet
 Ingo Melzer            DaimlerChrysler
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates
scribe: Adi Sakala

Wednesday 28 January
13:00 Introductions and logistics
    - Assignment of scribes
        (Igor Sedukhin), Adi Sakala, Arthur Ryman, (Prasad Yendluri), 
        (Dietmar Gaertner), Tom Jordahl, (Jeffrey Schlimmer), 
        Philippe Le Hegaret, William Vambenepe, Umit Yalcinalp
    - Agenda bashing
    Scribes: Adi, Arthur, Tom, William, Philippe

13:10 Publication plan
      Survey of remaining work
        Part 1: Open issues:
                  misc (16)
                  editorial (2)
        Part 2: Open issues:
                  misc (1)
                  editorial (1)
        Primer: ?

Resolve the current 17 issues and 3 editorial issues.  Should be able
to go to last call on all parts by May and internally freeze within 
the working group by March.

Primer by may should be mostly in the hands of editors.

RDF mapping of wsdl 2.0, this proposal will be done parallel to other 

Charter says we have a testsuite deliverable.

Test Assertion Document:

Paul:     Says it is very important for people looking at these specs
          and trying to evaluate.
Philippe: Testsuite could be owned by other groups not necessary by 
          wsdl working group.
Arthur:   The eclipse project hosts the java implementation of 
          wsdl and has test assertion document for wsdl 1.1. It would 
          be a good idea to have blessing from group for 2.0 assertion
          document. Is there an easy way to reference to spec from the 
          test assertion document?
Paul:     It would be a good idea to have the document done here so 
          that other groups can refer to it like ws-i.
JMarsh:   Resource constraints.
Philippe: How did xmlp group did this?
Glen:     Took all the assertions in the spec and converted them into 
          test cases and the actual testing was done by soap builders.
Jeff:     Can't really have a framework due to licensing issues.
JMarsh:   Have a bucket of wsdl's valid and invalid and make them as 
          test cases.
Glen:     It would be a good idea to go one step forward and actually 
          define how the wire messages look when something is defined 
          in wsdl.
Arthur:   Explains how eclipse does the validation of wsdl.
Glen:     Wsdl 1.1 has lot of problems due to not having wire traces 
          as test collection.
JMarsh:   Need to have a scope so that we can achieve it 
          appropriately as this is a big area.
Arthur:   If we host it at eclipse, companies who doesn't like 
          opensource won't like referencing it.
Dave:     Working group produces the interoperable spec. I think it 
          should be hosted by wsdl working group.
Robert:   Should we have bug tracking system, nightly builds etc.
Arthur:   The current goal would be to have a test assertion document 
          which eclipse can take and build test cases and run through 
          their validator.
Paul:     There is a commercial value in this document and we should 
          not sacrifice that value.
JMarsh:   It looks like there is an agreement to host test assertion 
          document here. Whether it should be in the same document 
          or as a separate document.
Jeffm:    Having markup is a starting point but not a test assertion 
          document itself.
Glen:     There are assertions in spec and there are n number of 
          things that each assertion can fanout for testing.

RESOLUTION: we should have a separate document for test assertions 
            and this document has to be explicitly linked to the 
ACTION: Phillpe and JMarsh will look at the ipr for test suite.
RESOLUTION: Arthur is the Editor for this document.

13:30 Faults
    - Issue 105: Abstract Faults [3]
      Work through some WSDL examples to verify that Paul's
      fault proposal [4] doesn't negatively impact bindings.

  [3] http://tinyurl.com/ysgl#x105

Pauls Proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0064.html
TomJ:     writing some fault samples on white board for discussion.
  <interface name=Ifoo>
    <fault name=BadTicker message=ns:faultelem/>
    <operation name=myop>
      <input message=ns:myinelem/>
      <output message=ns:myoutelem/>
      <outfault name=tns:BadTicker/>
  <binding name=IfooBinding>
    <wsoap:fault name=tns:BadTicker>
Roberto:  The intent of soap spec is people should be able to resolve 
          faults by looking at faultcodes instead of digging into 
          detail element.
Glen:     In wsdl we should be able to specify the hierarchical fault 
          codes that soap allows.
Umit:     How to distinguish faults on per operation basis.
Glen:     Message should really be element as it really pointing to 
Umit:     Should we be able to allow two soap faults to be associated 
          to a single fault definition.
Glen:     You can bind one of the fault at the top level and define 
          more specifics at the operation level.
Paul:     The binding spec is behind. I don't think someone looked 
          into it.
Roberto:  It should be something like <outfault ref="tns:BadTicker"/>
          I think it should be "ref", because we usually use "name" 
          when defining a new component, not in references.
Bijan:    I just want to note that the issue of renaming message 
          (especially to *element*) touchs on an action item of mine 
          (that I'm finally understanding). First, I understand 
          message to mean message*type*. If so, I don't want to 
          restrict messageTypes to elementTypes.
Tom:      Take fault to fault in binding and just don't give any 
          flexibility to override for different operations.

RESOLUTION: Accept Paul's proposal to hoist faults in the interface.
RESOLUTION: Rename faultDefault to fault.
RESOLUTION: Allow <value>,<subcode> as children of 
RESOLUTION: Remove per-operation (in|out)fault
NEW ISSUE:  Open issue on the name of wsoap:fault/@name and 
            outfault/@name (should indicate that it is a reference, 
            not defining a name)
ACTION: Sanjiva to consistify the @name attributes.

14:00 Issue fault-name-uniqueness [5]: Should faults be named with
      QNames? In WSDL 1.1 fault names are NCNames which are not unique
      within portType even. This leads to a cumbersome mechanism to 
      uniquely identify a fault.
  [4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0064.html
  [5] http://tinyurl.com/ysgl#xissue%20fault%20name%20uniqueness

Glen:     Why cant we make interface names as URI's so that binding 
          makes easy.
Dave:     How does symbol namespaces effect this??
Glen:     What if we make targetNamespaces of wsdl as part of the 
          namespace and combine it with interface name to make a URI?
          Eg: wsdl namespace http://foo.com, interface A, operation 
          getFoo. Then referring to operation will be Qname of, 
          http://foo.com/A, getFoo
Roberto:  Explaining the uniqueness of operation in case of 
          inheritance scenario. Qname of operation name should be 
          unique in the context of an Interface.
[2nd Issue in Faults closed.]

RESOLUTION: Close issue-fault-name-uniqueness - works just like 

14:15 Issue 89: Binding message references in component model [6]

  [6] http://tinyurl.com/ysgl#x89
Roberto:  Create two message reference components at binding level 
          to be in consistent with abstract level. With the fault 
          resolution at the binding this might not be an issue 
Sanjiva:  We need to keep things in consistency.
RESOLUTION: Close issue 89 by changing the namespace of wsoap:fault 
            to wsdl:fault, and add a corresponding component in the 
            abstract model.

15:00 Break

15:20 Issue 87: Redundant direction information [38]
        a) Drop direction property.
        b) Retain direction property.

 [38] http://tinyurl.com/ysgl#x87

JMarsh:   Redundant direction information in our abstract model.
TomJ:     What would be ramifications for removing this model. This 
          information is useful to validate the part 1 information 
          that it is pointing to appropriate MEP.
Glen:     MEP has appropriate names and by looking at it you know 
          what you are doing.
Sanjiva:  Removing the direction property. Since now we made 
          messageReference optional, by using input and output name 
          you can determine the direction.
JMarsh:   How does this work when you use defaulting model. And if 
          we don't understand the message pattern then this property
          should be useful.
RESOLUTION: Close issue #87 with no action.

15:30  Optional Extensions (Latest Issue from Email thread [.1]):

[.1] http://www.pacificspirit.com/blog/2004/01/28/extensibility_and_ignore_rule_in_web_architecture

Glen:     The issue here is our spec doesn't say anything about the 
          processing of extensibility elements.
Dave:     What if somebody ships a processor that has a default 
          behaviour and throws error on every optional element. The 
          wording in spec should ensure us.
Paul:     There is a must understand tag.
Dave:     The default is if we don't specify must understand the 
          processor should continue processing and not fail. 
Jeff:     Want to have a policy for faulting on unknown things. 
          Agrees with backward compatability argument of dave but 
          would like the wording in such a way that if process wants 
          to fail they can fail based on a policy.
Dave:     This is a problem with the using should and must.
Glen:     Optional extensibility elements should be ignored.
Robert:   If we agree on marking it as should understand, can we 
          produce a test assertion for this.
Glen:     SOAP has these constraints in the spec so that tests can 
          be shown to work.
Dave and Roberto: Optional extensibility elements must be ignored.
Arthur:   What happens in generating code, rendering html, editor 
          editing WSDL etc.
Umit:     If I process an extensor and mark it in the abstract model 
          how do I know which state I am in?
Dave:     We can live with should ignore as long as we have test 
          cases in the test assertion document.
Prasad:   +1 to DaveO's latest proposal; SHOULD ignore with some of 
          the execeptions enumerated
Philippe: "Optional extensions MAY be ignored. Unknown optional 
          extensions SHOULD be ignored" "Known optional extensions 
          SHOULD be processed. Unknown optional extensions SHOULD be 
Prasad:   How about optional extensions a WSDL processor can not 
          process successfully SHOULD be ingored :)
DaveO:    Roberto brought up the issue of conformance.
JeffM:    Prasad, the conformance issue is how to have a conformance 
          test with a SHOULD as opposed to a MUST.
Prasad:   Thanks Jeff. Yup thats always an issue. However conformance 
          testing should not be a sole criteria why something is a 
          SHOULD. MUST is a *bad* choice here.  HTML and WSDL are 
          very different though. What applies to HTML is not at all 
          applicable to WSDL IMHO.

Straw Poll
  1. Statement in spec, that a wsdl processor MUST ignore the optional
     extensibility element.
  2. Statement in spec, that a wsdl processor Should ignore the 
     optional extensibility element.
No Resolution and still an OPEN ISSUE.

16:30 Joint Session with Arch WG
    - Summary of Arch deliverables and areas WSDesc should be aware of
    - Use Cases document disposition
    - Issue 90: Synchronize terminology [7]
    - Issue 75: Incoherence between WSA and WSD MEPs [8]

  [7] http://tinyurl.com/ysgl#x90
  [8] http://tinyurl.com/ysgl#x75
  - WSA now have a much more useful usage scenario document now.
  - WSD group is lack of resources to work on this document moving 
  - Need to review the work done by the WSA working group on usage 
  - talking about glossary and inconsistency of terminology in the 
    WSA specification documents.
  - The hope is to adopt the WSA terminology in the WSDL working group.
  - WSA group will be flagging gap about soap intermediaries.

17:30 Adjourn
Received on Wednesday, 4 February 2004 12:49:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:37 UTC