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

Minutes, 19 May 2004 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 24 May 2004 21:48:28 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA203B6C8AF@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Group
Minutes, FTF meeting 19 May 2004
New York City, hosted by IBM.

Wednesday 19 May

 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Hugo Haas              W3C
 Amelia Lewis           TIBCO
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Jerry Thrasher         Lexmark
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

Phone (part of the day):
 Ugo Corda              SeeBeyond
 Yaron Goland           BEA Systems
 Jean-Jacques Moreau    Canon
 William Vambenepe      Hewlett-Packard

 Tom Jordahl            Macromedia
 Hao He                 Thomson 
 Kevin Canyang Liu      SAP

 Marc Goodner           SAP
scribe: Jeff
09:00 Introductions and logistics
    - Assignment of scribes
        Jeff Mischkinsky (1), Roberto Chinnici (2), 
        Amy Lewis (3), Youenn Fablet (4), Sanjiva Weerawarana (5)
    - Agenda bashing

Part 1 and 2 -- we never quite hit zero bug bounce, but on hold 
for the moment -- about 10 issues -- probably deal with in 

Part 3 - get to zero issues - or at least plan for each issue

The usual getting the network going.

Random discussion about schedules, magical person month myths, etc.

Tentative last call june/july. Revisit later in meeting.

09:15 Media Type Description Note [2]
    - review status, open issues [3, 4], content
    - raise issues, next steps
    - Goal is to approve pub as Working Draft

  [3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x161
  [4] http://www.w3.org/2002/ws/desc/2/06/issues.html#x162

Umit presented the current Media Type proposal.

Q: What happens when there is a mismatch between expected and 

Declare a ws that accepts a range of media types, but the actual 
message sends a media type out of the range.
Umit: assumption is that this group may need to define faults for 
error codes.
Discussion about whether we need to do this. This can't be 
handled via schema validation.

mt1. possible error conditions: mismatch between value of media 
     type attribute and pattern -- says nothing about the data 
mt2. possible error conditions: mismatch between the media type 
     attribute and the actual data 
mt3. Is acceptMediaType the right name for the attribute.
     valid?, expected? permitted? emitted? (suggestions) 
mt4. where should appInfo go -- on the type and/or element?
mt5. remove or describe fully multipart and message -- i.e. the 
     composite types 
mt6. acceptedMediaType should be able to be a list 
mt7. Consider changing name from mediaType to contentType 
mt8. Would like more examples:
     e.g using a static type -- i'm always going to use an 
     image/jpeg. What would that look like?
mt9. Explain why this proposal is limited to base64encoded?
mt10. Explain why */* AND absence means this is opaque 
      application data (i.e. application/octet-stream.
mt11. Pattern includes use of priorty -- either explain 
      relationship or get rid of 
mt12. How do annotations show up in component model? (currently 
      limited to a "binary information element")

Jonathan raised question of whether this proposal could be more 
generally applied to base64 attributes. Consensus seemed to be 
that's going too far our purposes.

Question as to timing. David observed that this is de-coupled 
from the last call, and that this will be note. We do however 
have to coordinate with XMLP.

Issue mt5 Proposal: remove composite types
    *** UNAN accepted

Issue mt3 Proposal: rename acceptMediaType to expectedMediaType
    *** UNAN accepted

Issue mt6 Proposal: make expectedMediaType a list
    *** UNAN accepted

[ACTION: Media type editors to implement these resolutions prior to

Plan -- umit to communicate to XMLP the above issues and 

[ACTION: Umit to communicate to XMLP the above issues and resolutions.]

Take up when to publish thursday or friday.

10:45 Break     ----------------------------------------

scribe: Roberto
11:00 Review of Part 3

We took 30 minutes to individually review the latest part 3 draft.

The review identified the following issues:
[179] put and delete need to be added (Hugo) 
[180] inconsistent propagation of soap:header/module and F&P (Roberto) 
[181] bind to other protocols (JJM) 
[182] defaultMEP inheritance - syntax or model? (Marsh) 
[183] wsoap prefix (Sanjiva) 
[184] MTOM serialization into SOAP body (Ugo) 
[185] eliminate wsoap:header (Sanjiva) 
[186] interaction between wsoap:header and wsoap:module (Umit) 
[187] interaction between MEPdefault and webMethodDefault (Youenn) 
[188] wsoap:address vs http:address (DaveO) 
[189] binding message content to URI (DaveO) 
[190] layering of SOAP webmethod on top of HTTP binding (DaveO) 
[191] relationship between SOAP MEPs and WSDL MEPs (Hugo) 
[192] 2.4.1 "increasing specificity" -> "decreasing..." (Amy) 
[193] header declaration at different levels (Youenn) 
[194] why interleave wsdl: and wsoap: elements? (Glen) 
[195] property value merging (DaveO) 
[196] f&p/module at operation level vs input/output message level (Asir)

11:30 Issue 72: MTOM support [5]
    - Jean-Jacques' proposal for @mediaType, @reinsert [6]

  [5] http://www.w3.org/2002/ws/desc/2/06/issues.html#x72
  [6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0295.html

Marsh:    Is "MTOM serialization into SOAP body (Ugo)" all that is left
          to do? What do we need to do to indicate that a client needs
          to use MTOM serialization?
Glen:     Isn't there a header already defined in MTOM?  First of all,
          the media type will be different, and that's going to appear
          in WSDL as a flag.
Marsh:    What should the flag look like?
Glen:     Many ways to do it: an extension, a property, a full new set
          of bindings.
Amy:      What we do should be reusable; e.g. an extensibility 
          attribute of type anyURI to indicate the serialization.
Glen:     Why not use a feature?
Amy:      It's overkill.
Glen:     No, it's the same amount of work.
Marsh:    Then what are the conformance requirements? the expectations
          may be different for features and attributes.
Amy:      You can mark the feature as required.
Marsh:    As a user, I'd like to find an appendix in the MTOM/SOAP 
          specs that tells me how to enable it in a description.
Glen:     I know that MTOM is a feature, but we should confirm that 
          MTOM+XOP is a feature.  Then all it takes to enable SwA is 
          to write a wrapper feature for it (but that's out of scope 
          for the WG).  MTOM defines the "HTTP transmission 
          optimization" feature.

RESOLUTION: We'd like to describe MTOM availability using our feature
            mechanism and we need to coordinate with the XMLP working 
RESOLUTION: Close issue 72.

ACTION: Glen to write an example of expressing MTOM in WSDL using f&p 
        and send it to the XMLP WG.
ACTION: Editors to include in the primer an example that uses MTOM.

11:45 Issue 96: Intermediaries [7]
    - Jean-Jacques' proposal for @mustUnderstnad, @relay [6]

  [7] http://www.w3.org/2002/ws/desc/2/06/issues.html#x96

Glen:     Certain attributes on wsoap:header are only useful when 
          describing intermediaries e.g. @mustUnderstand on a header 
          addressed to a notarization intermediary, because I want 
          to make sure that if there is such an intermediary it 
          will do the right thing.
Amy:      Don't you need these attributes for modules too?
Glen:     Not necessarily.
Amy:      It comes back to the "let's get rid of wsoap:header" 
          discussion.  Are we going to invest in wsoap:header?
Marsh:    If we remove wsoap:header, do we remove the ability to 
          describe intermediaries altogether?
Glen:     It'd be harder to do the same thing with modules, it would 
          affect the module specification.
Amy:      Your module specification should take that into account 
          already if there are multiple roles.
Marsh:    If we remove wsoap:header, isn't someone going to write the 
          add-a-header module?
DaveO:    Yaron did, it's ADD.
[discussion on how it could be done with wsoap:module only, but that 
seems to require nesting of properties under modules.]
Glen:     A module that uses five headers would define five 
          independent mustUnderstand properties, if needed.
Umit:     If the tweakability is not defined in the module I want to 
          use, I have to define my own module. But today with 
          soap:header it's a lot simpler.
Glen:     Example of two related headers, "challenge" and "response"; 
          in general, determining the tweakability points is hard.
Marsh:    And for a user it would be even harder.
Amy:      Strawman:
          <wsoap:module mustUnderstand="list of QName" 
                        role="list of pair {QName, QName}"/>
Glen/Youenn: Lists are not good enough, the rules are too complex.
Marsh:    Couldn't we address the simple cases and leave the hard 
          ones to the modules?
Amy:      What is the common case?
Glen:     For WSRM, the common case is the complicated one; for WSS, 
          the common case is simple.
Amy:      Can we expose a simple mechanism that works in common cases?
Glen:     In the simple case, wsoap:header is not bad.  Or use an 
          anonymous module.
Amy:      But modules don't work for HTTP, only SOAP.
Glen:     It's important to have wsoap:module, because they are in 
          the SOAP 1.2 spec; there are two other issues: is it 
          important to be able to specify generically headers and 
          set attributes on them? and if we do, can we tweak the 
          module syntax to do it or should we stick to wsoap:header?
Umit:     But aren't we making migration harder?
Marsh:    If I want to add a new header, I can with wsoap:header 
          without forcing me to update my processor (to understand 
          a new module and process it correctly).
Ugo:      If there are multiple intermediaries, is there only one 
          WSDL file or several ones?
Glen:     The endpoint in the WSDL file is what the client talks to; 
          that WSDL may contain knowledge about some intermediaries.
Amy:      But if it has a description, it's a service, it cannot be 
          "just" an intermediary.
DaveO:    Analogy with HTTP; in WSDL, interfaces are not constrained,
          so we cannot constrain intermediaries and we should allow 
          all of them to be described.
Glen:     Distinction based on whether the client is aware of an 
DaveO:    HTTP makes that distinction too (gateway and proxy, 
Marsh:    Are there any use cases we want to rule out?
Ugo:      You are focusing on the client side, the traditional use of 
Amy:      Disagrees, we're focusing on the contract for a service.

12:30 Lunch     ----------------------------------------

13:30 Intermediaries (cont.)

back form lunch, discussion continues
Enumerating the possibilities:
1) keep wsoap:header and add @mustUnderstand, @role, @relay, @reinsert
2) add @mustUnderstand and @role to wsoap:module (for simple cases) 
Amended the wsoap:module proposal to rename @mustUnderstand -> 
@setMustUnderstand and change @role's type to be a list of 
{QName, uri}

Glen:     Anonymous module proposal amounts to giving a choice between
          using @uri or @setMustUnderstand/@role, i.e. if @uri is 
          omitted the module is anonymous and the other attributes 
          must be present.
Amy:      Don't understand the direction this is going, prefer to use 
          properties to do that.
Marsh/DaveO: Essentially ADD does the same thing in the abstract, and 
          then it trickles down to the SOAP binding.
Amy:      Except that it'd have to be amended to make headers appear 
          directly under soapenv:header.
DBooth:   what would Tom say?
Roberto:  wsoap:header is direct, understandable and it works, so 
          let's just do that.
Hugo:     I like the first form, but maybe we don't have the tools to 
          use it, and we should go with the second one.
Asir:     Likes both, would like wsoap:header to be under wsoap:module.
Glen:     There is an elephant in the room, i.e. that you need to 
          understand the semantics to use headers effectively, the 
          data definition alone is not enough.
Marsh:    (describes the case of application-specified data)
Allen:    Then we're saying in most cases we got just the illusion of 
DBooth:   Likes to use existing features, like f&p, to solve the 
          problem, if possible. Cringes.
Glen:     Another proposal: come up with a convention for property 
          names made available by default by every module to tweak 
          flags on the headers (supported by those modules).
Roberto:  How is that simpler?
Glen:     Avoids additional syntax.
Roberto:  In the wsoap:header case, the syntax matches the concepts, 
          so it's simple for users.
Prasad:   Without a module wrapper around a property, we preclude 
          having different modules use the same header.
Amy:      +1 on Prasad's comment.  Would like to get rid of one of 
          the constructs, wsoap:module or wsoap:header.
Glen:     We need to keep both the simple and the complex cases in 
Umit:     The most general one is features.
Glen:     There is a reason for the existence of features, bindings, 
          modules.  XMLP wanted to enable naming the semantics that 
          HTTP (say) provides natively in an abstract way, so that 
          equivalent functionality could be provided via SOAP 
          modules (in the SOAP world).  An abstract feature is a 
          kind of interface; a binding implements a feature.  
          Modules bring multiple headers together and implement one 
          or more features.
Umit:     Maybe then the features in WSDL are different from those 
          in SOAP.
Glen:     No, at the abstract level there is no difference.  Having 
          separate bindings and modules in WSDL makes it easier to 
          add the support for certain features to a binding, without 
          requiring a new binding.
Umit:     We could add an attribute to a feature saying "use module 
Amy:      Agrees with this direction.
Glen:     Disagrees.
Marsh:    As we keep talking about this, the scope of the 
          conversation is widening more and more.
DaveO:    Question about the relationship between bindings/modules/
          features/properties in SOAP and WSDL, can they be brought 
Glen:     Features and modules are the same in WSDL and SOAP.
DaveO:    Are properties the same too?
Glen:     Yes.  (drawing a diagram) a module implements zero or more 
          features.  The *specification* for a module will list the 
          features it implements.
DaveO:    This apparent complexity is necessary because we have 
          extensibility in terms of MEPs, protocols, etc.; if we had 
          stuck to request-response HTTP, there wouldn't be a need 
          for it.  Another example is correlation between request 
          and response, that (in general) needs to happen at the 
          SOAP layer.  So if the world agreed to use, say, 
          WS-Addressing to do correlation, we wouldn't need a 
          correlation feature.
Glen:     #1 yes, #2 no, because if you go there you violate all the 
          assumptions that were made in creating web services.
Marsh:    We are back to redesigning SOAP now.
Glen/Sanjiva: When you see wsoap:header, either your infrastructure 
          recognized the QName there as, say, a security header (and 
          then it's not going to change the application), or it does 
          not, but then the application needs to know about it; the 
          idea is that if anything can affect the application 
          interface, it should be in the abstract.
Marsh:    Then you're saying it's either totally in the application 
          or in the infrastructure.
Paul:     But the case of headers with a role attribute is different, 
          because they go to an intermediary, not the application.
Glen:     Even if the header is destined to an intermediary, somebody 
          has to put it in there.  The ADD feature describes the data 
          being passed in the abstract.
Paul:     I must be able to describe existing interactions that use 
Roberto:  If the application has to set properties somewhere, it 
          doesn't make any difference if the WSDL used a wsoap:module 
          or a wsoap:header.
Umit:     Are we back to the time when we had a headers="..." 
          attribute on an input message?
DaveO:    The problem is that schema doesn't give us enough 
          functionality to do what we want, hence the need for ADD.
Sanjiva:  The SOAP binding says that the contents of the body must be 
          the element specified in the abstract.
Youenn:   If you define a headers attribute you encourage people to 
          use it.
Roberto:  Not having the headers attribute makes the cost of creating 
          new bindings lower (one less requirement to support).
Marsh:    Do we need to reopen the whole issue?
Sanjiva:  No, the current issue is only at the SOAP binding level.
DaveO:    We could define a soap module that allows inserting a 
          header and make wsoap:header syntactic sugar for it.
Glen:     Pull out wsoap:header now and see if we need it.
DaveO:    Easier to take stuff out at last call than adding it in.
Marsh:    For the specification, the other way is better.
Roberto:  We need to cover both uses of soap:header in our spec: in 
          the abstract, that's ADD, at the SOAP level it would be a 
          standard module that can be used to insert a header.
Paul:     Agrees.
Marsh:    Anybody opposed to removing wsoap:header, with the 
          understanding that we will define a module that allows 
          headers to be inserted (perhaps using the ADD) no replies?
Glen:     Everyone needs to understand that by doing this we are 
          pushing handling of role/mustUnderstand to module writers.
Sanjiva:  Isn't using role/mustUnderstand in ADD at the abstract 
          level a SOAPism?  Proposal: the ADD feature only declares 
          the QName of the element; then the default binding rules 
          for SOAP will make that into a header, without requiring 
          a module; finally, mustUnderstand/role can become 
          properties to be used in the SOAP binding.
Glen:     Friendly amendment: define a SOAP module anyway, don't 
          default it.
Roberto:  Objects to removing soap:header unless we provide a 
          standard way to insert headers at the binding level 
          discussion... if the ADD and property merging issues are 
          solved, then we can eliminate soap:header without losing 

RESOLUTION: Close 185 by removing soap:header
RESOLUTION: Close 186 as obsolete
ACTION: Editors to remove soap:header.

Add issue 195 for property value merging; merge 193 and 195, since 
they are related. [Previously added.  193 closed later on.]

15:30 Break     ----------------------------------------

15:50 Discussion of Issues opened this morning

scribe: Jeff
Issue 181: bind to other protocols (JJ)
    Editorial/descriptive glitch --  drop the word "only" from 2.2.2 
    SOAP Binding Component and describe what happens if a different 
    uri is used, but it MUST be compatible with wsdl soap binding
    Accepted -- UNAN

RESOLUTION: Close issue 181 by dropping the word "only" from 2.2.2
    SOAP Binding Component and describe what happens if a different
    uri (which must be compatible with the wsdl soap binding) is 
ACTION: Editors to fix 2.2.2 to allow other protocols.

Issue 196: Module operation at operation level vs input/output level


Issue 180 and 193 -- related

For a given interaction, a module is either present/not present and 

Question is how to merge when the "tree" is collapsed. Closer to leaf 
overrides, with exception of required-ness. Amy wants to be able to 
turn off required-ness and availability, without pushing all the info 
"down" the tree, which the current rule requires (so to speak :-).

Mechanism -- default-<attr>value applies at a particular level and 
<attr>-value for particular instances at a level.

How are modules connected to interface? Not directly. If a feature is 
required in the abstract feature, then a module which implements the 
feature is not required.

[Conversation is more complicated than can be captured by the poor 
scribe in a linear fashion typing at finite speed.]

Sanjiva -- can have rules for how modules are combined which are 
different from combining features and properties.

Stwapoll: Who believes it is important to be able to shut off 
required and availability
    4 - yes 8- no

Amy registers objection that this is ugliness and treating req/avail 
as special cases in this way will be confusing.

Sanjiva Proposal: a module has 2 attr, a uri and req flag and if have
more than one module with the sam uri in scope then resolve by going 
up the tree - msg->op->interface. (nearest enclosing scope wins -- 
i.e. std lexical scoping rules in block structured programming 

Glen observes that this is different from what's in features and they 
should be the same.

Proposes that if we adopt sanjiva's proposal, then we should also 
change the rules for features.

EG: soap module is required at binding level -- then within operation
i can turn that off. is this ok?

Q: a. define a color=red at interface
   b. define color=red at msg level 4 times

Is there a difference in semantics? There could be a difference in the
semantics if the module takes into account at what level it appears. 
Not clear that the spec accurately says this. (editors will check)

RESOLUTION: Both Proposals are accepted UNAN
ACTION: Editors to make propogation of modules and f&p use the
        nearing enclosing scope.

NEW ISSUE: 197 Don't override interface features that are required in 
binding (umit)

Issue 182 - defaultMEP inheritance-syntax or model?
    Is this pure syntax or is there a semantic implication?

Should be pure syntax, component model mapping is wrong in spec. Also 
true for webMethodDefault and defaultMethod in HTTP binding.

RESOLUTION: Change component model to remove default* properties,
            use mapping from syntax instead.
ACTION: Editors to fix component model to remove default* properties,
        use mapping from syntax instead.

18:00 Adjourn
Received on Tuesday, 25 May 2004 01:03:55 UTC

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