- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 15 Jun 2004 09:50:53 -0700
- To: <www-ws-desc@w3.org>
Minutes, Web Services Description Working Group
10 June 2004 telcon
Present:
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.
Regrets:
Josephine Micallef Telcordia/SAIC
Bijan Parsia University of Maryland MIND Lab
Adi Sakala IONA Technologies
Igor Sedukhin Computer Associates
William Vambenepe Hewlett-Packard
--------------------------------------------------------------------
Agenda
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
binding.
?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
bound.]
?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
190)
?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
190)
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
attribute.
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
attend.
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
b. MTOM/XOP
- 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
[.3]
http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/att-0029/QA_Oper
ational_Checklist.htm
[.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
optimization.]
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
optimization.
[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
optimization?
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
Optimization.
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
optimized?]
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
optimization?
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
signatures.]
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:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0055.html]
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
Ajourned.
Received on Tuesday, 15 June 2004 12:51:28 UTC