W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2003

Minutes, 22 Sept 2003 WS Desc WG FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 29 Sep 2003 17:08:52 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2014607AE@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Group
Minutes, FTF meeting 22-24 Sept 2003
Palo Alto, hosted by SAP.

--------------------------------------------------------
Monday 22 September
--------------------------------------------------------

Present:
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Steve Graham           Global Grid Forum
 Tom Jordahl            Macromedia
 Jacek Kopecky          Systinet
 Philippe Le Hégaret    W3C
 Kevin Canyang Liu      SAP
 Lily Liu               webMethods
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Jeffrey Schlimmer      Microsoft
 William Vambenepe      Hewlett-Packard
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

Phone:
 Amelia Lewis           TIBCO
 Jean-Jacques Moreau    Canon

Regrets:
 Youenn Fablet          Canon
 Steve Lind             AT&T
 Ingo Melzer            DaimlerChrysler
 Adi Sakala             IONA Technologies

Agenda [0]

[0] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0140.html

--------------------------------------------------------
Scribe: Jeff Mischkinsky

09:00 Introductions and logistics
    - Assignment of scribes:
      Umit Yalcinalp (Wed), Jeff Mischkinsky (Mon AM), William Vambenepe
      (Tue AM), Tom Jordahl (Mon PM), Philippe Le Hégaret (Tue PM), 
      Lily Liu, Jacek Kopecky

Logistics [1], dial-in numbers [2] (members only).

  [1] http://www.w3.org/2002/ws/arch/3/07/f2fSeptLogistics.html
  [2] http://www.w3.org/2002/ws/arch/3/07/f2fSeptLogistics.html#Bridge

--------------------------------------------------------
09:15 Removing message.  New Draft [3], schema [4]
    - Countdown to close the following issues [5].
      * Issue 27: Remove 'style' attribute [6]
      * Issue 39: Binding extensions depend on structure of
                  portType [7]
      * Issue 40: Binding extensions for SOAP interact in a
                  complex way [8]
      * Issue 45: fault/@use should be optional [9]
      * Issue 48: soap:body/@use should be optional [10]
      * Issue 63: soap binding violates separation of abstract
                  and concrete [11]

  [3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml
  [4] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xsd
  [5] http://lists.w3.org/Archives/Public/www-ws-desc/2003Aug/0004.html
  [6] http://tinyurl.com/mwuy#x27
  [7] http://tinyurl.com/mwuy#x39
  [8] http://tinyurl.com/mwuy#x40
  [9] http://tinyurl.com/mwuy#x45
 [10] http://tinyurl.com/mwuy#x48
 [11] http://tinyurl.com/mwuy#x63


Marsh:   Objections to closing 27, 39, 40, 45, 48, 63 - going once, 
         going twice, ... SOLD  ... They are now closed.

RESOLVED: Issues 27, 39, 40, 45, 48, 63 are closed.

--------------------------------------------------------
    - Rules for @encodingStyle [12, slide 18]
      * No default value
      * If not given then no information about the "style" of
        the operation's elements is available.

A proposal was floated to rename to encodingStyle to style to differentiate
it from the SOAP encoding.

RESOLVED:  Consensus to add attribute named style -- no default 


--------------------------------------------------------
    - @encodingStyle="http://www.w3.org/2003/ws/desc/rpc" [12, slide 19]
      * The input and output elements have been defined according to
        a pattern indicated by these rules.
      * Input/output elements contain only local element children
        (i.e., no global elements allowed). (No <choice> etc.
        allowed? Not sure but probably should say so.)
      * Input element's name's localPart and operation/@name are the
        same.
      * Output element's name's localPart is
        concat(operation/@name,"Response")
      * Input and output elements are both in the same namespace.
      * The child elements of input and output represent input and
        output parameters of the operation. ("<part>" in WSDL 1.1)
      * If there exists foo such that there are child elements named
        foo in both input and output elements, then that represents
        an in/out parameter.
      * If there does not exist any such foo in both elements then
        all the parameters are input-only and/or output-only as
        appropriate (depending on whether they're in the input or
        output element).

Discussion of whether to have extensibility point
[TomJ:    Except when we are using "RPC", which is currently the only 
          thing we expect to be put there]
Make clear not required.
[Roberto: wsdl:rpcStyle="true"]

Straw poll - boolean flag for using rpc rules or uri?
non recorded results - boolean: 4, uri: 9, abstain: 2

Discussion on wording in spec on what is going to be required if the uri is present.
[sgg: 6.1.1 of the current editor's draft of part 1 states:]
[sgg: Mandatory extensions are those that MUST be processed correctly by the WSDL processor. If a mandatory extension element is processed, the WSDL processor MUST either agree to fully abide by all the rules and semantics signaled by the extension element's qualified name, or immediate cease processing (fault). ]
[sgg: note: it doesn't state that the processor can simply "stop processing" a single component]

ACTION: sanjiva to clarify wording on op style to say that use of uri is assertion on part of author and if the schema doesn't match then it is an error.

--------------------------------------------------------
TOPIC: specific rules for style='.... rpc'
2nd bullet: why no global elements?
Proposal to add another bullet: First param if it is out-only is result
Restate: if the first param in the result message is an out-only then it is the return, otherwise there is no return value
Going once, going twice --- SOLD good enough for publication next week.

RESOLVED: Add another RPC style rule: "If the first param in the result 
          message is an out-only then it is the return, otherwise there is
          no return value.

Proposal: restrict these rules to XML Schema only and its a sequence
RESOLVED: Restrict these rules to XML Schema only and model as a sequence

Umit: allow nillable and min/max occurs for each element
RESOLVED: Allow nillable and min/max occurs for each element

Discussion about unique wire signatures, operation name, etc. -- deferred until discussion of proposal snajiva posted


 [12] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0161.html

--------------------------------------------------------
10:30 Break
10:50 Binding enhancements.  New draft [13, 14]
  - Unresolved proposal: Drop <soap:binding>: drop @protocol, change
              <soap:address>: add @protocol.

 [13] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml#Binding
 [14] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml#Endpoint

Sanjiva:  Get rid of soap:binding element and add info to soap:address.
[JacekK:  glen, SOAP 1.2 says Protocol Binding, so attribute protocol is good (because protocolBinding would be confusing with WSDL bindings, IMO)]
glen doesnt want to call the attribute protocol - 
[GlenD:   protocolBinding]
Compromise position - call @ protocolBinding
Sanjiva:  Observes there is no transport specific info in the binding, so
          move it to the endpt.

Discussion follows -
Motivation: make the binding more "reusable"
Tom:      Doesn't see compelling use case for reuse.
Glen:     I have a soap binding - uses reliability, tx, etc. I would like 
          to reuse that info, w/o haviung to rewrite it for each specific
          endpt/protocol.
Sanjiva:  So if i'm using soap/http and soap/jms, I'd have to copy the 
          info -- AND maintain it.
Jacek:    Argues this proposal adds to what I have to know about the 
          endpt.
Sanjiva:  The binding and endpt info really are coupled.
Jacek:    Minuses -- currently need binding qname and endpt url, with 
          Sanjiva need to add soap protocol uri.

Straw poll -- 5-5- 7 or so abstentions
[JacekK: is the reusable-bindings stuff still in the queue?]
Marsh -- appears that proposal does not have widespread support -- so we will continue with the status quo

--------------------------------------------------------
  - Issue #84: Are SOAP header faults needed? [15]

 [15] http://tinyurl.com/mwuy#x84

TOPIC: are soap header faults needed
Glen:    Describes in soap that when there is a fault associated with a
         header, then the "detail" fault info goes in the header.  
         Specified in bp 1.0.
Consider req-resp case -- if there's a problem in the body -- get back a soap fault, hopefully with relevant info in the detail.
If there's a problem with a header -- get back a header, a "header fault", with the relevenat info about what was wrong with the header, in the returned header.

Defer issue.

--------------------------------------------------------
12:00 Lunch
--------------------------------------------------------
Scribe: Tom Jordahl
13:00 [agenda change: Binding Enhancements (cont.) replaced with:]
      Media type handling in WSDL 1.2 (Philippe) [43, 44, 45]
      - Update on MTOM (Jean-Jacques? Glen?)

[43] http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0028.html
[44] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0088.html
[45] http://www.w3.org/2003/09/0912-media-types.html 

Jacek summarizes SOAP MTOM project and current status
[dbooth:  MTOM = http://www.w3.org/TR/2003/WD-soap12-mtom-20030721/]
[dbooth:  (Message Transmission Optimization Mechanism)]
[jeffsch: FYI here's the predecessor to MTOM: http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html]
[dbooth: Philippe's presentation on Media types: http://www.w3.org/2003/09/0912-media-types.html]
Phillipe: Describes media type problem - type info is in binding, hard 
          to generate interface bassed on Schema/portType only. If we 
          move the type information to interface, we can only type a 
          single element, which is too limiting. So we need to move the 
          type info in to the Schema. Oulines possible solutions:

          1. PASWA WSDL definitions - WSDL defines new xmime:Binary 
             type that can be used in Schema. Also defines WSDL schema
             extension, xmime:Accept. SOAP extension: Element has a 
             xmime:MediaType attribute.
          2. Schema type extension.  No SOAP extensions, just use xsi:type.
             Just use the namespace http://iana.org/mime, and the types it
             defines.
          3. Schema Annotation. Keep mime content and move it to the
             annotation element of the XML Schema. Also requires SOAP 
             extension for mediaType attribute.
          4. Schema notations. Create one notation for each media type, 
             then use feature of XML Schema to reference them as notations.
          5. Use the TAG mapping between URI to media types.
Discussion on the merits of the various solutions....
Jonathan: Thinks there should be a simple way to map the binary defined 
          in the schema to a single mime type.  Outlines an extension
          attribute to simpleType that would simply indicate the mime 
          type of the binary data.
Discussion continues on how to make Jonathan's simple proposal work.
[dbooth:  It's important that an off-the-shelf XML Schema processor be
          usable in the case when the application doesn't care that the
          base64binary is specifically jpeg.]
Jonathan's Proposal: Create a NOTE to hand off to XML Schema and/or XML
          Protocol Working Groups defining the namespace and attributes 
          for mime type.
Looking for a volunteer to write up a note describing new Schema attribute approach.
Jaff S. points out the the issue needs a champion, or it may not get done.
[Marsh: ACTION: potential editors to apply to Chair :-)]

--------------------------------------------------------
14:00 Patterns.  New draft [16]
    - Choose specific patterns for the standard [17]:
      1. TF recommendation: drop the old request-response (defined
         in terms of "same channel") and drop one of the multicast-
         solicit-response patterns, as subsumed by others [18].
      2. Sanjiva's proposal: drop any pattern not used in a
         normative binding in our spec.
      3. Tom's proposal: drop the "multi" patterns.
      4. Amy's proposal: at least the patterns in WSDL 1.1.

 [16] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.xml
 [17] http://lists.w3.org/Archives/Public/www-ws-desc/2003Aug/0010.html
 [18] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/recommendations_clean.htm

Proposals:
1. drop the old request-response pattern. The IN/OUT pattern now clearly
   specifies that the OUT goes back to the node that sent the IN.  We are
   left with 6 patterns now in the current draft: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.xml.  [Marsh: seems to be
   consensus that we already accepted TF recommendations.]

2. Sanjiva: Drop anything without a binding in our spec.
3. Tom: Drop the multi-cast
4. Amy: Keep at least what we had in WSDL 1.1.

The above are proposals from various people.  Several arguments for keeping patterns even though we don't have bindings for them.
Jonathan: keep patterns in spec for CR, examine any work that attempts 
          to create bindings for patterns that we didn't?
Sanjiva:  Let's take a shot at creating bindings for the patterns (like
          OUT/IN) we don't have bindings for.
Much discussion about history of the patterns and how users may use patterns we don't spec bindings for.

15:00 Break
--------------------------------------------------------
15:20 Patterns (cont.)

Three options:
1. have patterns in spec
2. have patterns in a note
3. let the industry do the work, we don't specify them
[jeffsch: Kevin, do you mean this? http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0054.html]
[KevinLiu: yes. thanks for dig this out, Jeff.]
JeffSch:  Don't take these patterns out and prevent him and others from
          taking advantage of them. Makes a strong statement to keep the
          current 6.
[Roberto: keep those for which there is a normative binding (currently 2)
          and publish the other ones as a note]
[jeffsch: SOAP Email Binding http://www.w3.org/TR/2002/NOTE-soap12-email-20020626]
[jeffsch: (May be only request-response)]
[jeffsch: Sanjiva proposed retaining all 6 patterns in the normative part 
          of the spec but clearly identify which bindings support which
          patterns.
[jeffsch: As a compromise.]
Roberto:  The 4 are good, but the multi patterns seem very fuzzy.
[prasad:  I would like to observe that in most cases the same bindings that 
          are applicable to an interface of In-Out (In first) type of 
          pattern are also equally applicable to the interfaces that are
          based on the patterns like Out-In (out firrst). Only issue is 
          how to obtain the end point address for Out first patterns. This
          can be achieved via many out-of band (to the operation) means.
          Including using another operation in the same port to register 
          the end-point (wh...]
[jeffsch: From http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0044.html...
          The example only illustrates output-only, but it would not be
          difficult to construct a similar example that illustrated
          output-input.
Jonathan: Keep 4: IN and OUT.
Jonathan: Tell Amy we want to remove the multi patterns. See what happens.
Grumbling about removing multi patterns, particularly without some sort of binding.  Chair attempts to pin down the working group to decide if we are going to remove the mutli's and/or the OUT's.
[dbooth:  Sanjiva's proposal: (1) We retain all 6 pattern, and (2) We document which ones are supported in the bindings.]

Straw poll on Sanjiva's proposal:
For:12 Against: 3

Sanjiva:  Variant, cut the 6 down to 4 (remove multi's)
For:12 against: 4 (different people)
Vocal group would like to see viable binding proof of concept in order to decide if we remove the multi patterns.
Dbooth:   Conditionally approve Sanjiva's proposal to adopt the 6, subject 
          to seeing a proof of concept at the next F2F
[Roberto: and mark the multis as "at risk".]
Jonathan: Concensus on keeping 4, with 2 in danger of being removed unless 
          we see proof of concept binding.

--------------------------------------------------------
16:00 Binding message references in the component model [19, 20]

 [19] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0077.html
 [20] http://tinyurl.com/mwuy#x89

[inadvertently skipped?]

--------------------------------------------------------
16:30 WSDL Validator demo (Arthur)

Arthur shows the cool validator and makes a plea for others to join the project.
[Roberto: http://www.eclipse.org/wsvt/]
Interested parties can get info at that URL.
[plh-lap: linked from http://www.w3.org/2002/ws/desc/#tools]

17:30 Adjourn
Received on Monday, 29 September 2003 20:08:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:26 GMT