- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 24 May 2004 21:48:28 -0700
- 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
-------------------------------------------------------
Present:
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
Regrets:
Tom Jordahl Macromedia
Hao He Thomson
Kevin Canyang Liu SAP
Observers:
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
telecons
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
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-t
ypes.html?rev=1.4&content-type=text/html;%20charset=iso-8859-1
[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
mismatch?
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.
Issues:
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
publication.]
Plan -- umit to communicate to XMLP the above issues and
resolutions.
[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
group.
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
intermediary.
DaveO: HTTP makes that distinction too (gateway and proxy,
perhaps?)
Marsh: Are there any use cases we want to rule out?
Ugo: You are focusing on the client side, the traditional use of
WSDL.
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
simplicity.
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
mind.
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
foobar".
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
together?
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
wsoap:header.
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
functionality.
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
used.
ACTION: Editors to fix 2.2.2 to allow other protocols.
-------------------------------------------------------
Issue 196: Module operation at operation level vs input/output level
RESOLUTION: no objection to CLOSE NO CHANGE
-------------------------------------------------------
Issue 180 and 193 -- related
For a given interaction, a module is either present/not present and
required/not-required.
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
languages).
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