[corrected] Minutes, 10 June 2004 WS Desc telcon

Minutes, Web Services Description Working Group
10 June 2004 telcon

 Erik Ackerman          Lexmark
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Helen Chen             Agfa-Gevaert N. V.
 Roberto Chinnici       Sun Microsystems
 Ugo Corda              SeeBeyond
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Hugo Haas              W3C
 Tom Jordahl            Macromedia
 Jacek Kopecky          DERI
 Amelia Lewis           TIBCO
 Kevin Canyang Liu      SAP
 Peter Madziak          Agfa-Gevaert N. V.
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Dale Moberg            Cyclone Commerce
 Jean-Jacques Moreau    Canon
 Mark Nottingham        BEA Systems
 David Orchard          BEA Systems
 Arthur Ryman           IBM
 Jerry Thrasher         Lexmark
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

 Josephine Micallef     Telcordia/SAIC 
 Bijan Parsia           University of Maryland MIND Lab
 Adi Sakala             IONA Technologies
 Igor Sedukhin          Computer Associates
 William Vambenepe      Hewlett-Packard


0.  Welcome new members (was 4a):

- Mark Nottingham replacing Yaron Goland for BEA
- Jacek Kopecky returns, representing DERI
- Peter Madziak, Helen Chen join from Agfa-Gevaert N. V.

1.  Assign scribe.  Lucky minute taker for this week is one of:
      Erik Ackerman, Adi Sakala, Tom Jordahl, William Vambenepe, 
      Prasad Yendluri, Jean-Jacques Moreau, Umit Yalcinalp,
      Igor Sedukhin, Dale Moberg, Paul Downey, Hugo Haas

Scribe: Tom

2.  Approval of minutes:
  - June 3 (corrected) [.1]

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0041.html

Approved without comment.

3.  Review of Action items [.1].
PENDING   2004-04-01: Marsh will get schema tf going.
?ED       2004-04-29: Part 1 editors to adopt Jacek's "purpose of the 
                      binding" text, without "interchangeable"
                      endpoints, and using "confidentiality" (or 
                      similar) instead of TLS.
?ED       2004-05-19: Editors to include in the primer an example 
                      that uses MTOM.  (Issue 72) 
?ED       2004-05-19: Editors to make propogation of modules and f&p
                      use the nearing enclosing scope.  (Issue 180)
?ED       2004-05-19: Editors to fix component model to remove 
                      default* properties, use mapping from syntax 
                      instead.  (Issue 182)
?ED       2004-05-20: Editors to incorporate Hugo's full potato 
                      proposal.  (Issue 54)
?ED       2004-05-20: David Orchard to update HTTP binding to 
                      include discussion of how to generate an 
                      accepts header from schema annotations 
                      conformant to the media types extension 
                      document, and to use outputSerialization 
                      based on that information.  
?ED       2004-05-20: Editors to incorporate http:{properties} into 
?ED       2004-05-21: Sanjiva to implement the resolution that 
                      @soapaction not there means no soapaction.  
                      (Issue 1)
PENDING   2004-05-21: Part 2 Editors to add such a statement. 
                      (Issue 191)

Have to go back to minutes to figure out action item: Part 2 Editors to
add such a statement for issue 191. Amy will take care of it.
[* alewis quotes issue 191: Closed 5/20/2004 FTF. Will add a statement
to the introduction of Part 2 along the lines of "if you are familiar
with soap meps, wsdl meps are the same but a little bit more abstract".
Will add a statement to Part 3 relating WSDL MEPs and the SOAP MEPs

?ED       2004-05-21: Part 3 Editors to add a statement to relate 
                      each of the two soap meps to wsdl meps. 
                      (Issue 191)
?ED       2004-05-21: Editors to add ednotes to the spec to 
                      indicate areas that had contention.  (Issue 
?ED       2004-05-21: Editors to remove @separator from HTTP 
                      binding.  (Issue 190)
PENDING   2004-05-21: DaveO to write up a scenario to motivate path
                      creation on a per-operation basis.  (Issue 

DaveO action item: DaveO to write up a scenario to motivate path
creation on a per-operation basis.  (Issue 190)  Dave says he will do
this, and knows what it is.

?ED       2004-05-21: Editors to write up that we allow 
                      http:version etc. in the soap binding when 
                      the protocol is http.  (Issue 190) 
?ED       2004-05-21: Editors to update part 3 to say that for SOAP 
                      Response MEPs the URI will be generated 
                      following the HTTP binding rules for 
                      generating a URI (for GET).  (Issue 61)
?ED       2004-05-21: Editors to update soap binding default rules 
                      to allow use of MTOM. (Issue 184)
?         2004-05-21: Amy to provide wording to go into spec to say 
                      that our bindings only support the identified 
                      MEPs but others can be handled if appropriate 
                      rules are defined elsewhere.  (Issue 155) 
?ED       2004-05-27: Editors to add http:faultSerialization 
PENDING   2004-05-27: DaveO will write up better description of 
                      this issue (189).

DaveO will write up better description of issue 189 - partially
completed with Email.

Actions items for last week missing from agenda, JMarsh reviews:

DONE [.2] 2004-06-03: Jonathan to communicate this to the XMLP WG.
DONE [.3] 2004-06-03: Hugo to write a message for the WSD group to 
                      XMLP about the confusing name of http 
                      optimization feature
?ED:      2004-06-03: Editors to incorporate Paul's proposal with 
                      ONE http code.

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0020.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0073.html

4.  Administrivia
  a. New members:
   - Mark Nottingham replacing Yaron Goland for BEA
   - Jacek Kopecky returns, representing DERI
   - Peter Madziak, Helen Chen join from Agfa-Gevaert N. V. 
  b. Upcoming FTFs
     - August 2-4 (London)
       Logistics [.1], registration [.2].

Marsh reminds about the London F2F in August - encourages new members to
Amy inquires about teleconference facilities
PaulD: could set up a phone number in UK, but toll free is costly. Maybe
voice over IP?

     - September 14-16 (Toronto) [.3]
     - November (West Coast) volunteers needed

JMarsh: looking for a host on the west coast

[.1] http://www.w3.org/2002/ws/desc/4/04-08-f2f.htm
[.2] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Mar/0064.html
[.3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004May/0000.html

5.  Task Force Status.
 a. Media type description
  - 1st Working Draft Published [.1]

JMarsh: Media type working draft published

  - Last Call Published [.2]

JMarsh: XMLP published MTOM and XOP (along with a few others) - they
want WSD group comments. Volunteers?  Jacek agrees to review XMLP specs,
everyone else is encouraged

ACTION: Jacek to review XMLP specs

 c. QA & Testing
  - Suggested QA plan [.3]
  - More details from Arthur [.4]
  - Interop bake-off
 d. Schema versioning
  - Waiting to hear back from Schema on my draft "charter."
  - Henry's validate-twice write-up [.5]

[.1] http://www.w3.org/TR/2004/WD-xml-media-types-20040608/
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0052.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0037.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0019.html

6.  New Issues.  Issues list [.1].
  - Mark N's: See issues 207-225.
  - 208, 213, 215 are editorial - refer directly to editors?

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

MarkN issues are in: #207 - #225
Does anyone object giving the editorial issues directly to the
editors?.... No objections.

ACTION: Editors should correct issues 208, 213, 215, come back to WG if
there are any questions.

7.  Issue 207: How to mark which elements to optimize [.1]
  - See thread starting at [.2]
  - Related issue on F&P? [.3]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x207
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0020.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0042.html

Several Email threads were started on this, include the XMLP group.
XMLP (unofficial) responses seem to indicate that this is unnecessary.

DBooth:   Do we want to provide a WSDL mechanism to indicate what 
          to optimize? No - leave it to the mechanism
TomJ:     Leave it to the protocols to decide, not WSDLs business.
[dbooth:  If an optimization is required, then in essence it is a 
          different data type that must be sent -- not an 
Ugo:      Problem with leaving it to the mechanism.  Cases where 
          WSDL can further tune generic policies.  Would provide 
          additional benefits.
Mark:     XOP and MTOP are alternate serializations.  It would 
          seem natural for WSDL to support working with these.
JMarsh:   We do support it on/off, but it is it useful to describe 
          fine grain detail?
Ugo:      Optimize is cost/benefit.  The detailed hints could help 
          it a lot in many applications.  Saying MTOM should be 
          used only says use the processing model, doesn't 
          guarantee *any* optimization.
Umit:     Didn't we make a decisions to add a MTOM via a feature?
JMarsh:   Yes, the feature is there.  Do we want to provide 
          *additional* syntax that gives fine level control of 
[dbooth:  q+ to say that the use case is reasonable, but don't 
          call it a hint or optimization.  If it is required for 
          a particular element, then in essence it is a different 
          data type -- not an optimization -- and it should be 
          declared as such.]
MarkN:    To say that an element *must* be optimized goes 
          against the idea, hints might be useful, but requirement 
          is not.
[Roberto: strawpoll?]
PaulD:    +1 to Mark.  Any use cases for needed to require 
Ugo:      Use case - a server that provides images, a wireless 
          client may require optimization because it has lower 
          bandwidth.  Maybe a different binding for that client 
          that can express the optimization requirements.  Agrees 
          with Mark, it can't be required, must be a hint.
PaulD:    Nothing in that scenario that WSDL could help, you need 
          extra runtime info.
Ugo:      If I have a different binding that has the hints, 
          wouldn't the hints help?
PaulD:    If you are going to have 2, just define different 
          endpoints where one will always optimize.
Ugo:      If the second endpoint uses MTOM, still might not 
          have optimizations.
DBooth:   Confused, thought we would require, but now hears hint.
Ugo:      Can't force optimization, MTOM doesn't support it.
[PaulD:   i'm very confused by Ugo's use-case: we're talking 
          about hints for individual elements, why would a 
          lightweight client want one element optimised and 
          another not?]
Sanjiva:  We should NOT optimize.  Not 80/20. On/off is good 
          Enough. Half measures will not solve the problem.
JMarsh:   What do the SHOULDs in MTOM/XOP actually mean?
Mark:     The specs don't say anything about what should or 
          should not be optimized.
Hugo:     Changed his view, doesn't think we should 
          specifying which part should be optimized.
Asir:     Enumerated 4 possibilities of how optimization 
          could be done.  Would expect WSDL to be agnostic 
          toward any of the possibilities.  In favor of not 
          saying anything. If we say anything, it should be 
          a hint.
Mark:     Proposes that WSDL not say anything about 
TomJ:     Seconds the proposal to not say anything.
Umit:     Question - Can we change the proposal to say 
          base64 elements MAY be optimized?
Jacek:    +1 to Umit
[PaulD:   thinks type="xs:base64binary" is a good enough 'hint' 
          when serialising a message.]
[dbooth:  Straw Poll: Should WSDL provide fine-grained control 
          over which elements are to be optimized?]
JMarsh:   Strawpoll - should we provide fine grained control over 
          which element are to be/could be optimized.
Kevin:    How will the optimization engine work?
Mark:     Implementation specific - if looks like base64 
          canonical, you can optimize or not.
[Asir:    Pauld, it is more than type="xs:base64Binary" .. 
          Element content in base64Binary canonical lexical 
          representation; content MUST not contain any 
          whitespace characters, preceding, inline with or 
          following the non-whitespace content.]
Hugo:     How will the hints be used?
[Marsh:   Second straw poll: Do we want to use expectedMedia 
          type (or similar) for controlling what gets 
Jacek:    Used in some application where device constraints 
          mandate where certain things must be optimized.
[PaulD;   Asir, so i have an PNG image in memory, it has no 
          spaces, it's a binary image. AIUI the spaces only 
          comes into play when transforming an existing XML 
          document into a MIME package ..]
JeffM:    People will need these hints, if we don't do it, 
          who will?
[Asir:    Pauld, sure tho that is specific to one 
          implementation - transforming from binary to wire 
          xml content directly.
Mark:     Not an interop problem, its a control problem: How 
          much control do we provide in WSDL?
More discussion amongst various people about XOP support when when/how
it works.
[Prasad:  I am concerned we'll be leaving in a interop issue 
          we leave it to be a random local decision to 
          optimize which parts get serialized. XMLP punted 
          it to app level but, WSDL *could* help here. When 
          the feature is required, requiring certain types 
          (b64bin) to be optimized is useful. ]
Straw poll (again): Should we provide fine grain control of 
Result:   2 YES, everyone else NO 
[Marsh:   1st straw poll: 20 Nos.]

[PaulD:   Asir, so in the case of an existing base64binary 
          element with spaces on either end, it's a question 
          of how 'significant' the white space is?]
[Asir:    Pauld, I am not sure significance is the question 
          here .. about re-construction without breaking d 

Straw Poll #2: Do we want to use expected media type (or 
          something like it) to control what gets optimized?

Discussion on Straw Poll #2...
Confusion on why media type would help with optimization and what WSDL
would say about it.
[Pauld:   Asir, so if there was an indication that 
          insignificant whitespace was important (e.g. DSig 
          was in play), then that could be used a hint for 
          the whole message?]
Umit:     Suggestion to use MAY be optimized based on media type
More discussion about how the media type would be used ....
[Asir:    Pauld, possible .. not sure tho]
Umit:     We don't say anything about media types and optimization
          and we should at the minimum say that this info 
          MAY/SHOULD be used to optimize.
Mark:     Media types were not written for optimization.
PaulD:    Doesn't see how the media types help you.
Marsh:    Media type can be used in constructing better programming 
          models - which is orthogonal to optimization.
Hugo*:    Using media types to give a hint about what would be a good
          set of elements to be optimized is one of the many things
          one may want to express as optimization hints, an example
          of another one being a preference based on the size of the
          objects serialized. Just using media types is an arbitrary
          restriction, and the description of this set of preferences
          is orthogonal to basic MTOM support and unneeded for us.
[* http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0087.html]
[Pauld:   Media type doesn't help you know if you can optimise 
          a non-canonical base64string and discard whitespace.]
Asir:     Reminds us about Noah Mendelsons email suggestions.
[Pauld:   Noah's subtype proposal:

JMarsh:   Let's vote! 
Straw Poll #2: Do we want to use expectedMediaType for controlling what
gets optimized?
[dbooth:  Straw poll: Do we want to say anything about whether expected
media type MAY, SHOULD or MUST be used to control what gets optimized?]
Result: 11 Yes, 7 No, 4 abstain

JMarsh:   Now need to decide if the yes votes want MAY, SHOULD or MUST.
MarkN:    For the record, I support MAY, am strongly against SHOULD or 
          MUST, as they're against the spirit of MTOM/XOP.
[Pauld:   So a 1 pixel JPEG SHOULD/MUST become 100+ bytes attachment ?]
[Dbooth:  Straw poll: Do we want to say that expected media type: 
          (a) MAY be used to control optimization; or 
          (b) SHOULD or MUST be used to control optimization.
[Alewis:  Pauld, it's just a question of where it appears, isn't it?
          That is, those 100+ bytes are somewhere in the frame, just
          difference between attachment or inline, right?  And 
          between base64 versus bare bytes?]

Results: 16 MAY, 5 SHOULD


Received on Tuesday, 15 June 2004 12:51:28 UTC