[Corrected] Minutes, 24 Sept 2003 WS Desc WG FTF

[Updated with more detail for WSDL Component Designators]

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

-------------------------------------------------------
Wednesday 23 September
-------------------------------------------------------

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

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

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: 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
      attribute.
    - Proposal for advertising QoS features of a Web service in WSDL
      [42].

 [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 
          primer.
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">
            <value>http://example.com</value>
          </property>
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/...">
            http://example.com
          </soapaction>
Schema is 
          <schema ...  targetnamespace="http://www.w3.org../">
            <element name="soapaction" type="anyURI">
          </schema>
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: 
          http://www.w3.org/2003/09/0924-ws-desc-properties.html]
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 
          properties/features. 


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


Group is discussing options proposed in the document [47].
Roberto:   All the examples use the http scheme. How about others?
[some irc problems here while we discussed options in the TAG doc.]
Jonathan:  Proposes we remove this from our spec until TAG proposes 
           a solution.
Jacek:     Not all components require a URI.
Bijan:     RDF has a way (which scribe missed the details of) to name 
           indirectly the components.
Arthur:    R120 is in the requirements.
Roberto:   There is schema component designators which is not final. 
           Isn't this similar?
Arthur:    We should go back to urn solution which is not broken.
Bijan:     I am interested in the urn proposal and I don't think it 
           would be a problem with RDF.
Arthur:    We define urn:wsdl means this solves the deferencability 
           problem.
Jonathan:  Proposes that we move this to rdf mapping document and wait 
           for the TAG decision.
There is agreement on Jonathan's suggestion.

-------------------------------------------------------
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 
          about?]
[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. 
[jeffm:   VOTE, VOTE, VOTE, VOTE, VOTE]
[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 
  http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0172.html

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 Tuesday, 30 September 2003 20:17:15 UTC