Minutes, 24 Sept 2003 WS Desc WG FTF

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

Wednesday 23 September

 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
 Lily Liu               webMethods
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Jeffrey Schlimmer      Microsoft
 Steve Tuecke           Global Grid Forum
 William Vambenepe      Hewlett-Packard
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Steve Tuecke           Global Grid Forum

 Amelia Lewis           TIBCO
 Jean-Jacques Moreau    Canon
 Prasad Yendluri        webMethods, Inc.

 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: Umit

09:00 [Attributes | Endpoint References as needed, otherwise:]
      Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [40].
    - Arthur's proposal to unify property URIs and QName URIs. [41]
      Alternatives include using property markup, or a QNamed
    - Proposal for advertising QoS features of a Web service in WSDL

 [40] http://tinyurl.com/mwuy#x2
 [41] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0047.html
 [42] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0020.html

Arthur's proposal to unify property URIs and QName URIS.
What should be property or extension?
Glen:     Things affecting tools should be extensions, semantics 
          affecting interactions should be properties/features. 
Sgg:      Is it ws-policy? 
Glen:     This question should be resolved. This would be in the 
ACTION:   Glen to clarify when to use the open content model and when to 
          use the properties/features in the primer. 

Arthur's proposal [41]
          <property uri="http://www.w3.org/.../soap/SoapAction">
Arthur:   This is verbose and generic content model. Schema validator 
          can not impose the constraints. Propose to translate the form 
          into namespace + local name as illustrated below.
          <soapaction xmlns="http://www.w3.org/...">
Schema is 
          <schema ...  targetnamespace="http://www.w3.org../">
            <element name="soapaction" type="anyURI">
This allows schema validation. 
?:        How do you distinguish between the extension and properties?
Arthur:   In the document, there is a decl which indicates the namespace 
          to be a property namespace. 
          <wsdl:declaration ..../>
Glen:     We should keep the other syntax. For enumerations, it is easier 
          to express with the property syntax. 
Sanjiva:  The schema validation holds true for any syntactic sugar. RPC 
          pattern has the exact property. Therefore, the argument is 
          not compelling. For example we can use the xsi:type to designate 
          the values with another attribute. 
Arthur:   This translation gets the schema validation for free. 
Roberto:  Extensibility already provides this functionality. 
Jeff:     I like it because it is familiar. What does it mean to require 
          a property? 
Glen:     It does not make sense. When we say required on an extension, 
          the processor must understand. This does not apply to 
          properties as properties must be made available by the processor 
          so setting the value does not make a difference. 
?:        When do properties come up? In the context of the feature? 
Glen:     The properties are to be made available to the property "set"
          regardless whether a feature is used. The contract is to make 
          the it available. When you set a propery uri, it is ...
Phillipe: If we don't set the feature, how can I reuse the property? 
Glen:     The reuse them between the feature is to reuse the value. 
          <scribe missed the answer>
Roberto:  Lets postpone this discussion. The mechanism has to be defined.
          What this adds to the existing to the extensions to be marked 
          specially (which they you don't know what they do as you may 
          not understand the extension in the first place. 
Arthur:   If we have this, for example, JSR 110 can extract the properties 
          and store them. The generic processor does not have to 
          understand, a different step (processor?) can evaluate the 
          properties on top of the generic processor. 
[jeffs provies the table for comparison.]
[plh-lap: Jeffrey table: 
Philippe: Why should be restrict it to a simple type? 
Glen:     We should not. It is not restricted in the soap spec. 
Arthur:   Properties are defined in the spec. This is an alternate and 
          simple syntax. Lets decide and move on. 
Straw Poll:
In favor : 7, against: 4
Sanjiva:  I am not convinced that we need to shorter syntax. 
Paul:     I am not sure when to use the extensions and properties. 
Jonathan: Table this issue and track it before we make a final decision.
          [40] is deferred. 
[pauld:   I'm still unclear when to use a property or when to use an 
          extension - i'd like some  concrete examples
ACTION:   Jonathan to look into [42] and evaluate relationship with 

09:45 Media type handling in WSDL 1.2 (Philippe) [43, 44, 45]

Done Monday:

10:00 WSDL Component Designators [46]
      Draft TAG finding [47]

 [46] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0075.html
 [47] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0054.html

[No minutes?  Chair recalls that we were unable to quickly choose an ideal
candidate from the TAG draft finding, and thus approved moving the appendix into the RDF mapping document to eliminate a dependency of unknown duration.]

10:30 Break

Proposal for shortcutting operation syntax

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

Roberto:  The fault rules do not make the in/out fault elements redundant. 
Amy:      Message ref may be made optional is a good idea. I oppose 
          making the pattern attribute optional. Requires writing the 
          tools more complicated and would allow variability in the 
          implementations.  For example, some implementations will never 
          look for patterns, only implement wsdl1.1 patterns. 
Sanjiva:  This is not to change to change the component model. The 
          operation component must have the pattern associated with it. 
Paul:     Agrees with Amy it will lead to interop problems. 
Umit:     Observes that this is again a syntactic sugar. 
[alewis:  I like the consistency provided by required @pattern, too.  
          Easier to explain.  No exceptions.]
[jeffsch: This http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml#InterfaceOperation_Mapping
          Mapping for {message exchange pattern} would look something like:
          The actual value of the pattern attribute information item, if 
          present; otherwise, if there is only one message reference in 
          {message references} and that message reference has {direction}
          equal to 'in', then 'http://www.w3.org/2003/06/wsdl/in-only';
          otherwise if there is only one message reference in 
          {message references} and that message reference has {direction} 
          equal to 'out', then 'http://www.w3.org/2003/06/wsdl/out-only'; 
          otherwise if there are two mes...
Umit:     Agrees with amy. 
[Chair:   Defer vote until a telcon rather than perpetrate rash judgement.]

Proposal for making messageReference optional.

Roberto:  It is already optional in the spec. 
Sanjiva indicates that it is not complete, and requires more clarification. 
[Roberto: I agree.]
[alewis:  +1]
Jonathan: Shall we leave it as optional and add more clarification?
Umit:     +1
[alewis:  It might be better to phrase it as "the message reference 
          attribute is required, if the pattern contains more than one
          message in a given direction."  That is, rather than describing 
          when it can be optional, describe when it must be used.]
[Roberto: And how do you find out what the correct message reference names 
          are if you run into a pattern you don't know about?]
[alewis:  How do you do anything useful with a pattern you don't know 
[Roberto: You can still build the operation component and all its children.]
[alewis:  *shrug*  Make a rule in the patterns section that if a pattern 
          contains only a single message in a particular direction, its 
          name is "input" or "output" (depending on direction).]
Lily:     This proposal is only for human consumers, not really for the 
          wsdl generators. 
Tom:      Argues that even if we define a pattern attribute, the processor 
          will stop when there is an unidentified pattern anyway. The 
          processing does not change, you need to do the validation anyway. 
[alewis:  No.]
Sanjiva:  Is it worth adding it as it covers 90% of the cases? 
Amy:      Does not agree that this is 80/20 case. 
[pauld:   I think choice is a bad thing - I want canconical sytax.]
Straw poll:
  4 opposed. 8 agreed. 1 abstain. 
jj:       Compilates the compilation. 
We will vote on this next telcon after more review. 

Jeffsch:  There is an issue with the current with the spec as is which 
          needs to be resolved. 

Proposal for making operation/@name optional 

Roberto:  If the interface eliminates the name, the binding can not refer 
          to it and it is restrictive. The operation is the only way 
          available for reference in the binding. 
Umit:     Operation name does not appear on the wire, its only purpose 
          right now is for a reference only. 
Tom:      The name is significant for Macromedia's tools for helping users. 

Straw poll for adopting the proposal: 6 in favor, 5 against. 
We will defer this to a future telcon.

12:00 Adjourn [48]

 [48] http://www.cdsusa.com/

Received on Monday, 29 September 2003 20:10:04 UTC