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

Minutes: 4 Nov 2003 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 7 Nov 2003 15:17:48 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA201B62767@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Group
Minutes, FTF meeting 3-5 November 2003
Sunnyvale, hosted by Fujitsu.

Tuesday 4 November

 David Booth                  W3C
 Allen Brookes                Rogue Wave Software
 Roberto Chinnici             Sun Microsystems
 Glen Daniels                 Sonic Software
 Paul Downey                  British Telecommunications
 Youenn Fablet                Canon
 Tom Jordahl                  Macromedia
 Jacek Kopecky                Systinet
 Philippe Le Hégaret          W3C
 Amelia Lewis (phone)         TIBCO
 Kevin Canyang Liu            SAP
 Lily Liu                     webMethods
 Jonathan Marsh               Chair (Microsoft)
 Jeff Mischkinsky             Oracle
 Dale Moberg                  Cyclone Commerce
 Jean-Jacques Moreau (phone)  Canon
 Bijan Parsia                 University of Maryland MIND Lab
 Arthur Ryman (phone)         IBM
 Jeffrey Schlimmer            Microsoft
 Jerry Thrasher               Lexmark
 Steve Tuecke                 Global Grid Forum
 William Vambenepe            Hewlett-Packard
 Sanjiva Weerawarana          IBM
 Umit Yalcinalp               Oracle

 David Martin                 SWSI

Scribe: Paul
IRC:    http://www.w3.org/2003/11/04-ws-desc-irc

09:00 Pattern inference [6]
      (optional @pattern, optional @messageReference):
    - Tabled decision on optional @pattern to future telcon.
    - Tabled decision on optional @messageReference to a future telcon.
    - Sanjiva proposes dropping redundant {direction} property from 
      the component model [7]

  [6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0172.html
  [7] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0210.html

Marsh:    Quick background of subject - Sanjiva to outline proposal, 
          Amy & Jean-Jaques to reply 
Sanjiva:  Status quo syntax for operations, user has to remember pattern 
          uris (complicated), value for messageReference - not orthogonal, 
          only not user settable 
Marsh:    Two issues: could come up with better labels, and make it 
[Marsh:   http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0344.html]
Sanjiva:  Rename input and output are redundant 
Roberto:  So long as you understand the pattern 
Sanjiva:  Outlines the proposed new rules to derive optional values 
[jjm:     http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0013.html]
[alewis:  Amy's alternative proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0017.html]
jjm:      Remembering uri not a problem, easy to remember - basically the 
          same for many patterns. 
Paul:     Why not have the name of the message in the pattern tags? 
Amy:      Specifies single rule: one way messages can have a short-cut - 
          only for unambiguous MEPs 
DBooth:   jjm's if you do not know the MEP you would not know the 
          direction of the messages being passed 
Tom:      +1 to Amy's proposal 
Marsh:    Amy's proposal has extensibility point for URI for a pattern .. 
          Sanjiva's extension would be an error ? 
Sanjiva:  Combine best of both: we should adopt Amy's proposal as his 
          proposal builds on it. URI can override the default rule 
jjm:      Why is important to keep the direction of the message ? 
JeffSch:  Firewalls and other intermediaries 
Amy:      May be better off using the words "input" and "output" rather 
          than A, B, Request, Response, etc 
Sanjiva:  "input" "output" seems natural now, but may seem strange in the 
DBooth:   Name could be used as a heuristic, "inputXXXX" "outputYYYY" 
Sanjiva, JeffSch: some problems with jjm's proposal, element names can't 
          be in the WSDL namespace 
DBooth:   Let's decide on Amy's proposal 
[DBooth: Amy's proposal: 
     Proposed syntactic changes: 
      - Make 
        optional (this was one of Sanjiva's proposals) 
      - Introduce the following rule: 
        When a pattern contains only one message in a given direction, 
        then the messageReference attribute is optional. When a pattern 
        contains more than one message in a given direction, then the 
        messageReference attribute is required (to disambiguate which 
        message is defined by the element). 
JeffSch:  Let's come up with some text for this 
Marsh:    straw poll 
[Straw poll: Make the messageReference optional if there is only one message 
in the MEP (Amy's Proposal) ]
youenn:   Use schema to validate rather than infer the valid patterns. I 
          would like to study each pattern, write a schema extract and use 
          it to validate each operation, default value, missing messages etc. 
Marsh:    Is there enough value in writing schema extracts just to support 
          WSDL validators ? 
[DBooth:  DBooth's generalization of Amy's proposal: If the MEP has no more 
          than one message in each direction, then the messageReference 
          attribute for each message is optional, because it can be deduced 
          from the pattern. ]
[alewis:  Agreed. That was what I intended to say. Actually, that's what I 
          thought that I said.]
Scribe:   Clarification of wording ... 
Amy:      DBooth has presented well my original intention.
[DBooth:  Generalization 2: If the MEP has only one message in a given 
          direction, then the messageReference attribute for the message in 
          that direction is optional, because it can be deduced from the 
          pattern. ]
[alewis:  I can agree with that extension, though, because it makes sense to 
          me, too.]
Sanjiva:  confusion reigns .. 
[alewis:  Examples: 
  1 input: always does not require @messageReference 
  1 input, 1 output: always does not require @messageReference 
  2 inputs, 1 output: inputs *require* @messageReference. 
In my original proposal (as intended), output also required it. In the 
modified proposal, does not.]
TomJ:     Wants simple rules! 
Roberto:  And what about faults ? 
DBooth:   This doesn't address faults 
Amy:      Would like to see the outcome of yesterday's discussion before 
          covering faults in my proposal.
Sanjiva, TomJ: use similar simple rule for fault. 
[DBooth:  Fault wording: If the MEP permits only one fault in a given 
          direction, then the messageReference attribute for the fault in 
          that direction is optional, because it can be deduced from the 
JeffSch:  doesn't that bake-in FRM ? 
Sanjiva:  this wording isn't enough 
[alewis:  JeffSch: No, it doesn't bake FRM in. The fault wording counts the 
          places where faults can occur, and allows WSDL authors to use the 
          same shortcuts.]
[DBooth:  New wording: If the MEP (including its fault rule) permits only one 
          fault in a given direction, then the messageReference attribute for 
          the fault in that direction is optional, because it can be deduced 
          from the pattern.]
[alewis:  FRM: fault replaces message. MTF: message triggers fault] 
Sanjiva:  We're talking about deriving the inferend default value for 
Roberto:  I don't like it, there is an order requirement / significance.
Sanjiva:  XML has a document order concept 
Amy:      You have to look at the child element, sounds unnecessary complex. 
          URI isn't too difficult. 
jjm:      +1 
[Roberto: +1] 
[youenn:  +1]
Sanjiva:  It's going to be an extra burden to someone used to writing WSDL 1.1 
Amy:      Pattern URI saves a child element traversal 
TomJ:     It's not going to be that bad! 
Amy:      It's syntactic sugar, tools won't care or have any significant burden 
Roberto:  +1 to Amy 
youenn:   XML default for this attribute 
[TomJ:    So if the tools don't care, then we should do this because it is 
          for the human reader/writer. 
pauld:    +1 to youenn 
Umit:     syntactic sugar should be more explicit 
jjm:      This makes WSDL more complex, the URI rules have to be learned, 
          and extra burden to users 
pauld:    +1 to jjm 
Sanjiva:  These patterns are going to be very common and maybe written by 
          hand, so should be as simple as possible. 
[alewis:  I do not agree, and I *do* write all my WSDL by hand. And read 
          other people's WSDL. And *really* *really* want to *always* see 
          the nice @pattern uri, because it's unambiguous altogether.]
Glen:     I want something to happen here, and now! 
Straw poll: Should we make the pattern attribute optional in some fashion? 
            8 for, 10 against 
Marsh:    Status quo reigns as for now .. 
Sanjiva:  This issue is important to IBM. 
Marsh:    Anything else on patterns?  no, so take a break! 

[alewis:  David: we probably need action items for someone to write up the 
          @messageReference optionally. You had some good text for that, I 
[DBooth:  Amy, good idea. Please steal my text. :) ]
[JeffSch: FYI, I added the appropriate editorial for optional @messageReference.] 

10:30 Break

10:50 Features and Properties
    - Glen's Features and Properties musings [21]
    - Arthur's proposal to unify property URIs and QName URIs. [22]
      Alternatives include using property markup, or a QNamed 
    - Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [23].
 [21] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0144.html
 [22] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0047.html
 [23] http://tinyurl.com/mwuy#x2 

Marsh:    Inline schemas postponed (until tomorrow, if time), May cover 
          header item in this discussion.
Glen:     Outlines his overview document. 
[Roberto: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0144.html]
Glen:     New pattern from SOAP 1.2 not yet widely used but has great promise. 
          WS-Reliable-Messaging as a worked example.
Marsh:    How do we evangelise this pattern in our spec? 
Glen:     Properties can be set and used generically, or may be tailored to 
          a given higher-level spec.
Umit:     How do we know how WSDL and an external spec are tied together ? 
Glen:     It's the well known URI 
Umit:     By referencing an external spec WSDL may no longer describe the 
          messages exchanged.
Glen:     Dips his toe into headers discussion 
Umit:     My question specifically was about how a feature/property would 
          be able to "refer" to specific WSDL definitions. 
Sanjiva:  Difficult to define F&P in this working group, would like to move 
          this into an external policy framework. 
Marsh:    soapAction ? 
Scribe:   Glen and Sanjiva discuss how generic policy is .. 
JeffSch:  Concerned about scope of this discussion 
Glen:     Acknowledges richer policy frameworks may emerge in the future .. 
Roberto:  May be other policy languages such as RDF, F&P is immature and 
          maybe should be removed from the spec.
Marsh:    Maybe out of scope for this discussion.
Dale:     There is a requirement that F&P answers.
Sanjiva:  Open content ? 
Umit:     Uniqueness on the wire was going to be resolved by F&P and now 
          you are going to remove it ? 
JeffSch:  Group agreed to do something about uniqueness, push-back on F&P 
          is not related. other extensibility models exist. 
Philippe: Maybe remove them and add them in again later if required.
Sanjiva:  Concerned about wide impact F&P has on spec for something that 
          may not get used.
Bijan:    As someone interested in layering on top of WSDL, extensibility 
          is good, even if we don't have a concrete worked out use now 
youenn:   Discusses Roberto's concerns. Features are abstract and not at 
          the binding level. 
Roberto:  SOAP 1.2 binding needs to express what SOAP 1.2 does. we need 
          stronger requirements here. 
jacek:    Postpone discussion until we can discuss policy (or whatever) 
Glen:     Accept they're there now and move on. 
JeffM:    Leave it in there. purpose is for users, not us. 
JeffSch:  Microsoft may consider filing a minority opinion against F&P 
[Marsh and DBooth discuss where F&P would be described .. Primer ? ]
Dale:     Questions who would implement what and would these URIs be 
Marsh:    W3C is moving away from central registries. Not clear which 
          extensibility mechanism should be used when 
Philippe: It will be simpler to remove them now than later. 
Roberto:  Still troubled that best (or only) use of F&P may be policy. 
          what is the requirement for F&P ? 
Bijan:    Questions Marsh about procedure, at-risk and last call .. 
JeffM:    Let's just move on. 
Glen:     Pen in hand. outlines another (non-policy) example of F&P - 
          a notary service. 
Marsh:    What more do we need in the spec to better describe F&P ? Arthur's 
          proposal ? 
Sanjiva:  Only use we have is for soapAction, so maybe a specific 
          attribute better than generic mechanism.
Marsh, Sanjiva: is Arthur's proposal still alive ? 
Arthur:   I prefer not to discuss proposal until the F&P issue has been 
          resolved. Glen, will you champion my proposal on my behalf. 
JeffM:    Let's just move on. 
JeffSch:  Would like to see the impact on the component model of a first 
          class property versus open extensibility model. Yesterday we 
          decided on a 1st class property for parameterOrder 
Glen:     Here is a spec by which you can add things generically 
Sanjiva:  hot food has arrived! 
Marsh:    let's decide quickly! 
Umit:     why are people against this proposal 
Glen:     it's not clear to me 
Roberto:  any elements question implementation of new WSDL propertySchema 
          construct. This is a big step. soapAction doesn't justify this 
Glen:     just because we only have one or two examples now, doesn't 
          preclude others in the future 
Straw poll: adding propertySchema in lines of Arthur's spec 
            4 for, 4 against 
Marsh:    Abstains carried the day. can we not do this ? satus quo ? 
Glen:     Anyone want to lie in the road 
Marsh:    Anyone object to dropping the proposal 

Marsh:    soapAction *before* lunch 
[hubbub, near revolt.  Chair is undeterred :-)]
Sanjiva:  Discusses syntax with Glen and JeffSch. 
TomJ:     I like Sanjiva's proposal (from the list). 
JeffSch:  Why is the WG obsessing on syntax ? 
Philippe: With F&P we have a way to achieve this. this is a syntactic 
[further discussion on impact on component model]
Sanjiva:  Let's vote! 
JeffSch:  3 things: syntax, component model and structure and description 
          how component model speak about external spec, HTTP, SOAP, etc. 
          third part requires parlence of external spec. 
Marsh:    Do we care that we have two different component models for the 
          same thing? Maybe a canonicalisation issue in the future to address. 
JeffSch:  We have two parallel tracks at the moment. 
Glen:     Mentions possibility of another proposal 
Umit:     Is soapAction required ? 
Glen:     No 
[working group have full-bladders and empty stomachs.]
Marsh:   Lets tackle soapAction before lunch! 
Straw poll: retain a non-generic way of representing soapAction ? 
           for 10, against 2 
Straw poll: keep operation (versus action) 
           1 for, 3 against 
Marsh: can we live with <wsoap:action uri="uri"> ? 
[consensus for yes, pizza smell in room!]
Straw poll: URI in simple content or attribute ? 
[consensus for attribute]
[stampede for lunch.]

12:30 Lunch

13:30 Drop @headers
    - Proposal from Sanjiva [24]
    - Related questions from Youenn [25]

 [24] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0107.html
 [25] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0033.html

Issue: should headers be dropped from interface?  Reason: headers are part of 
Youenn:   appeal to an application data vs other data distinction
Umit:     Is a marker needed at abstract to indicate what is multiply 
          realized in binding?
Glen:     Point is that multiple header treatments still expressible in 
Youenn:   Describes an image processing service with alternative 
          parameterizations.  In some way one binding appears to use a 
          SOAP header to carry some image info or ref.  Use case is 
          maybe that we don't support partitioning app data in different 
          parts of a binding.
Sanjiva:  Presumption has been not to support that partitioning, maybe 
          we should
Lily:     Customers make use of headers for app functions
Glen:     Should we enforce app in soap body and metainformatin context 
          in headers?
Jeff:     Not ours to set soap conventions.
JeffM:    Where does wsdl allow the distinction to be drawn?
Glen:     Contract on what and where data placed, not of course on 
          dynamically selected values.
JeffM:    Wants the interface to include contract details.  If f&p 
          endangered and we trash headers aii in interface, then what is 
Sanjiva:  Headers attribute inadequate to document some attempted protocol 
          implementations. So drop them.
Glen:     The body is a big bag that bindings pull parts from. Big bag 
          encourages bad non-modular design. So headers attributes and 
          f&p support good modular design
JeffM:    In practice headers glommed on incrementally and ad hoc
jacek:    +1 Glen
tom:      Wakes up. Supports Sanjiva.
Straw poll: Remove headers attribute from interface and headers property 
            from the model
            13 for 1 opposed, none lying down in road
RESOLVED: Remove @headers.
ISSUE:    Should the body attribute be renamed since the contrast with 
          headers is gone?
[renaming fracas resumes]
Poll on which names are acceptable:
  15 ok with message
  15 ok with element
  5 ok with body
  14 for data
  many mj
  11 content
Preference poll on winners:
  8 favorite for message
  8 favorite for element
  1 favorite for data
Runoff poll on winners:
  10 for message
  8 for element
RESOLVED: rename @body to @message.
[Issue can be reopened if name seems confusing.]

ISSUE: Considering the details attribute in infault
poll called for whether to rename details att. message
  3 for details
  10 for message
RESOLVED: Rename @detail to @message

ISSUE: is there a proposal for removing headers from the binding
JeffSch:  Wants to have binding headers declarable as the bare fallback 
          support in wsdl 2.0
Glen:     Insists that this approach is either useless (except for cookie 
          case) or promotes bad design or both
TomJ:     Supports having binding header descriptions.
[general remarks about how much, and in what detail, and by what means to declare in wsdl:definitions]
poll to determine whether removing soap headers from binding
  many opposed
  2 favor
ACTION: Glen to write up his proposal and rationale on headers

ISSUE: headerfault
Umit:     Sample apps use it in ws-i

15:00 Break
15:30 Attributes [26]


ISSUE: Attributes
Umit presentation, uri to come to document
[Umit:     the presentation is 
[JeffSch:  http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Oct/0021.html]
Jacekk:    Propose to combine get set into one section
TomJ:      Driving force for feature has withdrawn request-- so?
Sanjiva:   One style uri confusing
JacekK:    No, point is one section in document, but one style might be OK too
ACTION:    Jacekk to make proposal on combining the get/set styles into one
[Discussion took up the subject of Sanjiva's and Steve Grahams posts.  ggf 
wanted first class treatment to meet objections against creating extensions 
to wsdl.  Result, however, might not be adequate for their needs "obfuscated".]
Sanjiva:   Resource attributes don't have to be captured in WSDL for resource 
           management goals.
[However, this is not necessarily a consensus view in the GGF]
Roberto:   Service itself could have properties needing management.
JeffM,Sanjiva: on stateless, stateful, resource behind service, also stevet.
Marsh:     Invite people to review and comment during last call on attribute 
           support adequacy for grid.
Sanjiva:   Predicts IBM will not urge wsdl attributes as way to offer needed 
           extensions for grid.
Marsh:     Removal of style and sections on attribute not motivated at this 
TomJ:      Says that the effort has been undermined by withdrawal of key 
JeffM:     ggf wish for us to provide this is critical factor on pulling 
[discussion of schedules, timelines impacting proposal to remove attribute style.]
straw poll (informative only - no action planned): favor dropping
  13 favor dropping and 5 against]
[People who had supported effort summarize their rationales for changing 
their view.]

Issue: Make @style a list of URIs?
Marsh:     Anyone volunteer to say how styles can be composed?
[no one steps up.]
[DBooth:   To be clear, a nice thing about a style attribute is that it places 
           no burden on implementors that don't care about it. A WSDL generate 
           the doesn't care about it doesn't have to use that style, and a WSDL 
           processor that doesn't care about it can alway safely ignore it. 
           For this reason, the cost of adding a style attribute to our spec is 
           minimal: only the spec-ese that is required to describe it. 
           (And Sanjiva adds: Plus the additional burden placed on other sp]

16:00 Updated definition of equivalence (Sanjiva)

[remaining for today, http binding and updates on equivalence]
Sanjiva:   Substitute interface compatibility for equivalence of service. 
           details to come.
Glen:      Does not think this should be undertaken by wg, could be cool 
           on a wiki blog.
[Some support for what Sanjiva wants is already in the spec. No further action 

15:20 http binding [27]

 [27] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0230.html

[Some brainstorming about how to update the HTTP binding.  Discussion will
inform Philippe who already has an action to propose an update.]

17:00 Multiple inline schemas [20]

 [20] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0074.html

ISSUE: treatment of multiple inline schemas
[pauld:   Norm Walsh's blog on schemaLocation:
[scribe lost connection, hope this stuff gets logged somewhere]
[Chair recreates:
  WS-I is revisiting issue of inlined schemas importing each other. 
  Current recollection is that it was to ban schema import pointing
  to a WSDL to mean importing any inlined schemas in that WSDL.
  Umit wants inlined schemas and imported schemas to behave the same way,
  e.g. schemaLocation is allowed and means the same thing in both cases.
  After some discussion, we decided not to restrict xs:import and xs:schema
  appearing in wsdl:types.  We will not constrain the strategies specific 
  implementations have for locating schemas (even embedded siblings.)
  The question of whether wsdl:import also pulls in schema components from
  wsdl:definitions/wsdl:types.  Some members expected it should - we need
  to check this out more thoroughly.]
17:30 Adjourn
Received on Friday, 7 November 2003 18:17:56 UTC

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