<asir> Jonathan, what happens to import & include issues? Are we discussing those issues today?
<dorchard> scribe:dorchard
<scribe> scribe: dorchard
<dbooth> Meeting: Web Services Description F2F
<dbooth> Chair: JMarsh
can't use schema types for xml 1.1, so we invented our own!
roberto's proposal: fix bugs in our type system
microsoft: complicatioins to support XML 1.1 outweigh benefits
rich salz: agrees, abstracting away.
daveo: support just XML 1.0
pauld: i wanted to support 1.1 given it's a W3C rec, but having seen the complexity introduced i now think we should just stick to 1.0
ibm +1
tom: we thought we could get away without any complications, but there are. time to remove.
Hugo: xml 1.1 is a w3c rec, not supporting may help prevent it from being deployed, allow xml 1.1 somehow
<asir> asir: drop xml 1.1 support, prefer to use XML Schema types, ideally XML Schema WG and Core WG should address the real problem (for pauld)
<Roberto> +1 to asir's statement
<pauld> yes, i'm now convinced it's schema's problem
daveo says some brilliant stuff about xml 1.1 not being adopted because of types. The types are the thing
jonathan points out xml core was focused on xml validation, not the types. And they didn't "purposefully" make it lame.
<Zakim> TomJ, you wanted to call the question: Should we drop XML 1.1 support from WSDL 2.0?
asir: schema wg needs to fix types.
roberto agrees with asir
hugo: at w3c ac, there were a #
of schema, wsdl, xquery, etc.
... at w3c ac, there were a # of schema, wsdl, xquery, etc.
people. They said we were doing the right thing..
<asir> Hugo, where can I find that joint report?
<hugo> asir, it's on MSM's to-do list; I have some personal notes if you want
<asir> that will help
more mutterings of "drop 1.1" from various wg members
Vote is 11 to 2 for removing 1.1
w3c, the 2 against, do not object.
<asir> obsoletes LC 23
RESOLUTION: close 74e, 75q, 89b, 89c as we have removed 1.1
David Booth extolls the virtues of his proposed definition...
DB does not want to add the "pattern" (scribe not sure what pattern is)
<Roberto> is that the definition in http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0088.html?
db if reply directed to a different address, this can be the same node.
<Marsh> Nov 70, Nov72
<hugo> thanks
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0070.html
<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0072.html
<pauld> prefer "agent" as opposed to "client"
daveo laughs that there seem to be problems with the URI for agent in web arch document
<kliu> support reuse "agent" definition from ws architecture document
<asir> support the use of the word 'agent' in this context, its ok
scribe is doing terrible job because he's recalling debates on the TAG and Web Services architecture of agent and service and node and client and server and requester and provider and sender and receiver.
proposal: A node is an agent., sometimes called client and service.
Note: it may be accessible by multiple protocols.
DB: refers to agent, but we don't use it.
JM: any objections to adopting David Booth's proposal?
DO: problem arises that in-out requires out message goes to same node, which can be seen as violating the in-out contract if one perceives "node" = different address. By changing "node" to handle multi-address.
no objections to adopt DB's proposal.
RESOLUTION: Add DB's text + "Note: " in 2nd sentence, and close issue 50.
<dbooth> http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0070.html
A concrete example is at http://www.pacificspirit.com/blog/2004/12/01/versioning_service_data_using_wsdl_application_data_feature
BEA is fine with having a "header" at the interface, as long as more than SOAP is supported.
BEA observes 2 HTTP headers of interest: content-location, as being used by Atom and HTTP applications, and WebDAV's depth.
<TomJ> I am supportive of the idea of putting back the concept of headers in place of the application data.
<asir> I would like to explore the abstract "header" at the interface level, as spelled out by DO
<asir> DO, extrapolationg, what will be relationship between "header" and SOAP Module?
asir, there's at least 2 headers needed: soap headers and http headers. I could see a solution of header at the interface level, then the soap Module means serialize as soap headers.
<asir> thanks DO
<Marsh> Tony: Why not use another term than "headers" - sideband data, etc. Keep it abstract from SOAP.
<TomJ> we got it wrong because we have at least one comment that said 'where are the headers?' We have abstracted headers so well that people don't even realize that Application Data is how you set headers.
<asir> :-)
<Marsh> DO: All(?) other protocols sem to have a concept of headers.
<TomJ> all the interesting one do....
<Marsh> ... Abstraction is leaky, that's just a fact of life.
<Marsh> ... Nothing wrong with stating that the data is intended to go in a header.
<Marsh> Tony: SOAP headers are special, you can have multiple headers that can be targetted independently.
<Marsh> Tom: WSDL needs to be able to describe that "these angle brackets go in a header".
<Marsh> Tom: Important last point that "header" is being used.
<asir> if there isn't any interest in re-introducing the concept of "headers", then another option is to rename AD to HD, that is header data
<Marsh> Glen: Not very much.
<Marsh> DO: How do you quantify that?
<Marsh> Marsh: Proposal is not to go back all the way to WSDL 1.1 headers, but to keep some of the benefits of AD, such as the requirement to mark WSDL:header generated headers, best practise about abuse.
<Marsh> Glen: Also likes the separation of the abstract feature and the SOAP module.
Tom, it looks like <soap:module uri="http://www.w3.org/2004/08/wsdl/module/AD" required="true"/>
<Marsh> Glen: For instance, I could bind it into a single bucket at the message level, which contains all the individual headers.
<Marsh> Glen: We could change the syntactic sugar.
<Marsh> Jeff: Feel like I'm viewing a hall of mirrors of abstractions that aren't going to serve people. You don't need as many layers.
<Marsh> ... A nice thing is that you don't have to reinvent minOccurs/maxOccurs.
<Marsh> Glen: Likes to be able to bind it to a single bucket header too.
<Marsh> DaveO: Or you could use multiple <header/> elements, but then you need to reinvent minOccurs/maxOccurs.
<Marsh> Anish: Proposal is to use cardinality using schema through a wrapper type.
<Marsh> DaveO: Yes, just as in the AD feature today.
<Marsh> Anish: So, you define a wrapper, containing a set of header blocks. In the case of SOAP, you throw away the wrapper.
<Marsh> Tom: Isn't that going to cheese off the schema folks?
<Marsh> Glen: No, no validation here.
<Marsh> ... This just controls serialization.
<Marsh> Tom: I have a schema element, with a complex type, and some XML, I can't just validate it.
<Marsh> DaveO: If you don't do it this way, you need to reinvent your own minOccurs, maxOccurs.
<Marsh> Anish: Assume in the case of SOAP, that on the wrapper element you couldn't define extra elements.
<Marsh> Glen: No wrapper element - it's a complex type.
<Marsh> Anish: Still might have attributes.
<Marsh> DaveO: We have define a new attribute - mustUnderstand...
<Marsh> ... We had proposed that we would reuse SOAP mustUnderstand, but people didn't like it.
<Zakim> asir, you wanted to ask a question
<Marsh> Asir: What are the differences between the proposal and the AD feature.
<Marsh> Glen: Syntax.
<Marsh> DaveO: 1) <header> in interface.
<Marsh> ... 2) SOAP binding extended to serialize these into blocks, though you can turn it off.
<Marsh> 3) HTTP binding, similar including the disabling flag.
<Marsh> Asir: Looks like first-class elements in the WSDL, why all the feature URIs?
<Marsh> Glen: Precision, and you can use an alternate generic syntax if you want
<Marsh> Glen: Also you can re-bind it.
<Marsh> Anish: Question about example.
<Marsh> ... <header> is at the level of <input>, <output>
<Marsh> DaveO: Oops. SHould be inside <input> or <output>
<Marsh> Glen: @element should be @type.
<Marsh> Tom: Elsewhere we point to elements only!
<Marsh> Glen: This is different, we don't serialize the type/element. So type makes sense.
i like the fact that this proposal allows me to exactly specify the cardinality of soap header blocks. WSDL 1.1 does not allow this and I see this as a short-coming.
But, i would like some time to look at it carefully before voting on it
<Marsh> Kevin: We should settle on one mechanism to refer to that.
but seems like the right direction
<Marsh> Glen: Yes. Should be type.
<asir> Me too, I would like sometime to read thru this proposal and ask more questions
<Marsh> DaveO: Could call it "container type" or something to make it clear.
<Marsh> ... "wrapper type", "disposable baggie".
<Marsh> Tom: Initial reaction, for good but not obvious reasons we're using a type. My desire is to say "this header = this element". More direct mapping into the type control we have for the body.
<Marsh> Anish: Cardinality needs to be specified.
<Marsh> Glen: Could have multiple <header>s to indicate cardinality.
<Marsh> Anish: But then you have fixed cardinality.
<Marsh> Anish : <header minOccurs = "" maxOccurs=""/>
<Marsh> Tom: How can you do this in WSDL 1.1?
<Marsh> DaveO: Can;t. Big bug in WSDL 1.1.
<Marsh> Tom: Still can't use generic schema processing on teh type - have to pull it apart.
<Marsh> Glen : Have to anyway.
<Marsh> Tom: Can't validate soap:Header block.
<Marsh> Marsh: Can't anyway. This doesn't define the whole Header block, just the structure of some headers in it.
<Marsh> DaveO: XML Schema can't validate that type even if constructed carefully, since security headers, etc. may be added.
<Marsh> Tom: I have to go look at the headers and match them up with an appropriate schema definition.
<Marsh> Glen: Have to anyway.
<Marsh> Marsh: Misleading for it to be a sequence since soap:Header is unordered.
<Marsh> Anish: Can't be an all because of determinism restrictions.
<Marsh> ... Why can't we just define minOccurs maxOccurs in our language?
<Marsh> DaveO: We could.
<Marsh> Glen: We need to do more work if we do.
<Marsh> Anish: What is the cardinality of the header element in WSDL (in this proposal)?
<Marsh> Glen: One.
<Marsh> ... We've already defined this, less monkeying around.
<Marsh> ... (in AD feature).
<Marsh> ack kl;
<Zakim> kliu, you wanted to ask a queston and to and to
<Marsh> Kevin: For the soap binding part, the @disable-header-module attribute means what?
<Marsh> DaveO: On possibility, everything gets serialized.
<Marsh> ... Or, set the flag, nothing gets serialize.
<Marsh> ... Or, set the flag to "guess" and the implementation can serialize as it wants.
<Marsh> Kevin: If I define a lot of headers, and then only use a few at the binding level...
<Marsh> DaveO: Wouldn't do it. You'd do a different type at the abstract level for each set.
<Marsh> Kevin: Some things might only make sense for the SOAP or HTTP binding.
<Marsh> Glen: Don't put those at the abstract level!
<Marsh> DaveO: I did think a bit about specifying which level...
<Marsh> ... I couldn't think of a case where you needed to mix and match.
<Marsh> Glen: Very rare to insert app data into HTTP headers.
<Marsh> ... when would you want to insert headers we don't control?
<Marsh> DaveO: contentLocation, webDAV headers.
<kliu> I like the new syntax for header in interface level, I am not convinced that we really need features in the binding level, we should also add a simple construct in binding level
<Marsh> Tom: proposal still contains dataHeader header?
<Marsh> Glen: Yes. Might want to use an attribute markup instead.
<Marsh> Marsh: QNames isn't unambiguous.
<Marsh> Marsh: WS-Addressing marks reference properties with an attribute when it inserts them. An attribute here would parallel that.
<Marsh> Tom: Can I specify other SOAP attributes too?
<Marsh> Glen: We didn't support that because for application data is targetted to the ultimate destination.
<Marsh> DaveO: Default can be overridden.
<Marsh> Tom: I could define in my header schema that it allows/required soap:role, client will have to set that appropriately.
<Marsh> Kevin: Can't we specify all this at the SOAP binding level?
<kliu> All I hear is that a set of abstract headers can only be used by a particular binding, then why do we need to do it in interface level at all?
<Marsh> Glen: transmits extra information along with the body.
<asir> Kevin, you have some good questions
<Marsh> Tom: Can use different bindings. Could be smoke signals.
<Marsh> Glen: Same thing as in WSDL 1.1, serializing some parts into headers. That's abstract info.
<Marsh> DaveO: Who decides whether it is mustUnderstand?
<Marsh> ... Is it the person choosing the binding, or the person designing the interface.
<Marsh> ... I think it's the interface designer.
<Marsh> ... Even if some bindings don't support it.
<Marsh> Kevin: Two cases, application data that makes sense. For infrastructure data, you'd put this in the binding level.
<Marsh> DaveO: This is for application data.
<Marsh> ... They'll use policy for infrastructure.
<Marsh> Anish: Strange discussion. Why would you put mustUnderstand at any level in WSDL?
<asir> this proposal brings together all forms of extensibility; Extension :=> SOAP Module (SOAP), Extension :=> Feature in HTTP Binding (HTTP) - an observation
<Marsh> Glen: Application designer knows about new bits of data - and he needs to tell how old clients work with the data.
<Marsh> Anish: Why is header special in that regard?
<Marsh> ... Sender decides whether to insert mustUnderstand or not.
<Marsh> Glen: WSDL is from the perspective of the WSDL author...
<Marsh> [not catching this discussion point well...]
looks like my point was completely lost
<Marsh> [trying to see about alternatives to ad:mustUnderstand?]
<Marsh> Tom: Bet we'll get some comments about pointing to a type not elements.
<Marsh> ANish: Do we have to add nillable back in too?
<Marsh> Youenn: Reminds me of the part discussion. Not different at the binding level, why not return to parts?
<Marsh> ... Don't see any semantic difference between headers and body at the abstract level.
<Marsh> Anish: We have to recreate what schema offers us, a majority just wanted to reuse schema.
<Marsh> Youenn: No semantic (therefore abstract) distinction between header and body data. All just parts.
<Marsh> ...WSDL 1.1 headers were very broken.
although soap 1.2 says essentially body is syntactic sugar for soap header with mu=1 targetted at the ultimate receiver
i think there is a big difference between data send as header and as body
body is what the main intent of the message
<dorchard> Kevin: don't see how Faults relate, allowed inFault or outFault.
<dorchard> Kevin: if fault is generated in header, then soap 1.1 fault details must be returned as a header.
<dorchard> relationship between header and rpc and rpc signature?
<dorchard> Glen: we don't say how impl sets these things.. prob some runtime
<dorchard> anish: specifically in case of soap, if headers are defined does that mean extra headers are allowed or not allowed
<dorchard> glen: extras are allowed
<dorchard> proposal: <input headerstype="foo"/>
<dorchard> slight, before it was <input><header wrappertype="foo"/></input>
<dorchard> slight mods, before it was <input><header wrappertype="foo"/></input>
<dorchard> proposal change part 2) attribute on header to say generatedfromHeader | marker="true", instead of current proposal for header block that lists header qnames
<dorchard> tom, will this cause problems?
<asir> don't understand part 2)
<Zakim> hugo, you wanted to ask for headers for faults
<dorchard> asir, we're talking about removing the element that lists the application data header qnames and inserting an attribute on each of the application data headers, ala what happened with ws-addressing.
<asir> thanks for the clarification
<Roberto> 1 hour break
<Marsh> OK, let's get started again.
<asir> we are disconnected
<Marsh> where's hugo
<Marsh> ?
<pauld> scribe: anish
<scribe> scribe: anish
glen: we discussed the role thing
before (once or twice) and we decided not to have soap specific
markup.
... what is important in the soap space - role, relay etc
... since it is app data, role is not so imp
... mU thou became a tool to do the Orchard-esk version
thing
... we decided that it was in face imp to express mandatoryness
at the abstract level
... thats why role is out and mU is in
asir: two things -- specifying
role and specifying ad:mU
... sender decides on mU
... so it is a hint to the sender
glen: the wsdl talks about
putting in a particular schema type putting it in the body, but
the sender decides as what goes in the body. So all of wsdl can
be considered as hint
... I can see saying that it is recommended, but it is up to
you
Jonathan: something like it provides a recommendation from the WSDL author
daveo: i don't agree with
this
... if you say this is what I accept then u are saying -- put
it on the wire
... one of the things to think about is the versioning
scenario
... imagine that a wsdl author deploys an interface that is a
purchase order
... when they want to go to version 2, they want to add
something that is mandatory
... one option is to create a new interface, take that PO and
wrap it in a container element
glen: perhaps thru extensibility
davido: this is one valid way to
version wsdl
... another way is to leave the app and deploy an
intermediary
... the internal app is going to leave it as is and the
intermediary slaps the mandatory extension and passes it
on
... it is easier to build an intermediary to do this thru a
soap header and say you must include it
tom: it was not my 80% usecase but a valid usecase
glen: it is possible to write an intermediary that transforms things
<asir> sure transformation is possible
<asir> wsdl 1.1 has mustUnderstand, that is part of the schema
[more discussion on what mU message means on the in and out message given that the WSDL is from the point of view of the service]
<asir> not part of any first class element in wsdl 1.1
daveo: i gave a concreate example of version
jonathan: can we think of
scenario where the service is mU and the client says that i
know better and so I'm not going to set mU
... there may be a conflict wrt to how mU works in SOAP and
WSDL
daveo: soap provides an extensibility model where it is mandatory for the receiver and then we have extensibility in wsdl. This allows us to leverage soap extensibility in WSDL
jonathan: the issue is whether when the client agrees to the contract, does it conflict with its ability to chose the value of mU
glen: no conflict
Jonathan: asir, do you now think that there is no conflict?
<asir> if the separation is there, i'll accept it
glen: between the wsdl and soap model?
asir: yes
jonathan: do u accept glen's assertion that the separation does exists?
asir: i need to think about it
jonathan: the assertion is that setting mU is no different from setting the contents of the body
glen: there is an art as to what
wsdl can/should express
... in the 80/20 bucket
asir: i will think about it
jonathan: there might be some ed stuff that can clarify this
asir: the other issue was whether role could be added
jonathan: is there any interest in doing this?
no one seems interested
<asir> my preference for adding role is very mild, just consistency
<asir> nothing else
[discussion about intermediary in the room]
jonathan: i haven't heard usecase for role
tom: in your proposal you do have role
glen: the original proposal did have that in
[discussion on what should change in the proposal]
jonathan: asir, no one interested in this
<scribe> ACTION: asir to think about mU and possible propose some clarification text
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC53
jonathan reads the issue text
glen: from the text it is optional, but we may want to revisit that
daveo: if you use the optional feature then u have to do what it says
glen: if you see wsp:policy and wsr:retry=5, if you are using wsr then it does not matter, but if you are, they u use it
tom: if in wsdl if you see in your input element ad:header wrapper type then you have to include it
jonathan: with my MS hat on, if i see a property that is required then i don't want to support the feature that the property belongs to
[discussion on required-ness of f&p]
tom: why don't we define the term soap header wrapper type without using f&p
daveo: does that change anybody's
mind wrt to this functionality
... if MS says they are not going to support the header element
if it is associated with f&p -- i would like to know
jonathan: if don't have to bake f&p in the architecture to scan for a particular feature/property -- so we may not lie on the road, but I would prefer it
tom: i have that preference too
jonathan: can live with it, but
prefer
... clarification would be that this is required and any impl.
that sees the paricular feature does the right thing
youenn and jeff leave the room at this point
<dorchard> stage left...
glen: we have a break at 3, can we just go on thru 4?
jonathan: lets see how it
goes
... we need to make it clear that this particular predefined
feature is required. The problem is that it is in two diff
specs. May be it should come back in part 1
[discussion on how to structure the specs and its parts and optionality]
jonathan: let's not solve this now, but we should think about this further
tom: i prefer that we replace
f&p syntax
... would like a straw-poll on this
informational strawpoll: do we want to base this on f&p or base it on attribute or something else in Part 1
scribe: alternate syntax for the
same thing
... not allowed to engage f&p syntax to engage this
option 1: f&p -- syntactic sugar
<dorchard> 1) syntactic sugar for f&p, 2) not f&p
option 2: do more work so that it is not longer f&p based
option 1: 4
option 2: 6
jonathan: this is an
informational poll to provide direction to the authors of the
proposal
... slight preference to option 2, but not significant
... if it is option 1, then should it remain in part 1 or part
2
daveo: if option 1 were to win then would it be moved to part1 cause it is required
<dorchard> I think option 2 got 6 votes, because Kevin added his vote.
hugo: question as to what this is about -- app data feature or the header proposal
jonathan: this is about header proposal
<alewis> part 1
<dorchard> anish, option 1 got 4 votes, not 5
<dorchard> ok
<scribe> new information poll: if we go with option 1 in the previous poll then should it be in part 1 or part 2?
<dorchard> poll is: if option #1 wins (keep as f&p), then 1) move to part 1/3 or 2) keep in part 2
option 1: part 1
<dorchard> remember this element is required...
option 2: part 2
<alewis> part 2
<alewis> (sorry, changing vote)
glen: i don't care, but we already have things in part 1 that point to other parts in a mandatory way
<Roberto> I like part 2 better
jonathan: closing the information poll without taking the poll
<kliu> Glen is willing to get rid of FP and put AD feature in part 1
<kliu> ...without using fp
tom: f&p is mostly harmless
if I don't have to deal with it. The syntax is unwieldly
... we fixed that and we have syntac sugar for header
... so now what we are doing is syntac sugar that makes the
optional thing required
... it is part of the core
... it should not be activated as a feature
daveo: there are things that are in f&p that are very useful. The framework helps here, so that you don't have to redo things again and again
tom: i find the framework difficult to grok
daveo: if there were 5 of these
things and all of them replicated what is in f&p
... the framework is all about reuse and it is not showing
that
tom: lot of other features in
wsdl can be defined using f&p but we did not
... I'm ambivalent with a slight -1 to f&p
<asir> believes that an header proposal that is based on extension will be lot simpler than a proposal that depends on F&P
jonathan: the issue that we are trying to solve is about headers and not f&p
glen: it would be less work for
daveo to keep it as is, instead of rewritting whats is
f&p
... i would go with less work for now and see how the f&p
objections pan out
[glen expresses his opinion about f&p and policy and frameworks and interop etc]
jonathan: we are not moving forward with the issue at hand
[conversation about f&p that has happened 'n' number of times before]
jonathan: looks like davido knows what he has to do
<pauld> ack ack ack ack
<scribe> ACTION: daveo to further refine his header proposal based on the input he has received during the f2f
<scribe> ACTION: daveo to further refine his header proposal based on the input he has received during the f2f
kevin: very confused about this
<kliu> I am confused because the poll shows a preference for option 2, but now we are asking David to go for option 1
<Marsh> Summary: David will create a proposal for a header attribute which is an alternate syntax for the AD feature. The attribute will point to a "wrapper type" and describe that each 'child' in that type becomes a header.
<pauld> ... or maybe RRSAgent ..
<dbooth> pauld, talk to Ralph Swick
<Marsh> ... The proposal will continue to use f&p underneath, and will thus need a clear normative reference to Part 2 (e.g. support for the feature is requried of all implementaitons.,
<Marsh> ... Not much objection to moving the text to part 1 as well, DaveO to decide what he wants to put forward.
<Marsh> ... Bindings will also have to change to process the header information.
jonathan: does anyone have a pet issue in this bucket?
<asir> i prefer LC61b
<asir> it is easy
<asir> one
issue LC61b:
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC61b
proposal from asir: mark as dup of 75a
75a has already been rejected (with no action)
arthur: i got a similar note from some internal to IBM
Jonathan: faults are actually reuseable then messages
arthur: perhaps the primer can
point this out with appropriate examples
... there is additional thing in faults about fault codes
jonathan: there is an extra layer in faults about fault codes
<scribe> ACTION: arthur to come up with primer text to show fault reuse and fault code
jonathan: any objections to close issue LC61b as dup of 75a
no objections
<asir> my next easy one is LC61c
RESOLUTION: issue LC61b is closed as dup of 75a
arthur: i think that the people
who are pushing for this should provide examples that leverate
this flexibility
... and provide examples for the primer
... i'm prepared to accept that this flexibility is needed, but
we need the motivation text
tom: so like a 3 in and one out MEP
arthur: when you have >=2 messages in the same direction then you need this
tom: how harmful is it to leave it alone?
arthur: not harmful but it would be nice to provide motivation
anish: since we allow any kind of MEP, this is helpful. I would see arthur's point of view if we don't allow such MEPs
jonathan: if I create a new MEP and use WS-Addressing then the messge labels help
<alewis> ack
amy: would like to second jonathan's point. We don't actually know what kind of MEPs will be used. So making it possible to create new MEPs is a good thing
jonathan: do you have an idea of what/how you want to use this extensibility
amy: potentially
... with choreo or bpel this might be useful
arthur: wsdl 1.1 had 4 built-in
MEPs and no one implemented the other two -- out-only and
out-in
... soap 1.2 has also two MEPs
... we had some flexibility and it was not used
amy: wsdl 1.1 explicitly states
that the two MEPs that you are talking about are
undefined
... it does not describe out and out-in. WS-I comes along and
profiles this
... there are other possibility then req-res for protocols
other than http
... i don't think this is doing damage, it is optional
... we will be doing a disservice by removing this
anish: soap 1.2 defines two MEPs but does not restrict definition of other MEPs
<alewis> arthur, the *spec* says that they aren't defined!
<alewis> read it!
arthur: i don't understand amy's comment -- why hasn't anyone implemented this
davido: we implement it
arthur: to summarize, the flexibility is harmless but it is unwise to leave it in if no one is going to use it
jonathan: can this be a CR criterion?
daveo: that seems reasonable
jonathan: ws-a uses the message label
<asir> I saw another IBM comment that says that messageLabel should be tightened and made 'required'
arthur: that refers to the component model
davidb: the other issue refers to
defaulting
... so that you don't have to explicitly have to have message
label
<asir> that is LC 71 for the pattern attribute
arthur: yes, the message label attr is required only when there are >=2 messages in teh same direction
davidb: then what is the issue?
arthur: "they" are complaining
about the additional knob that has to be supported in the
tools
... the more knobs => more time to implement this
... when in doubt throw it out
<Arthur> fyi, that quote is from Marks of Marks and Spencer who drastically streamlined their business processes
<pauld> BREAK
--- break ---
--- back ---
<Zakim> dbooth, you wanted to propose that messages are implicitly labeled in, in2, in3, out, out2, etc.
davidb: the solution to
implicitly lable messages in, in2, in3 ...
... u have to provide a schema for each message
... iow within the operation element, for each in or out
element they would be in sequence
<pauld> is there a MEP description language? can ws-chor map onto a MEP?
glen: does it because of lexical ordering?
davidb: yes
amy: lexical ordering is called out as unimportant
glen: we'll have to change that
<Zakim> alewis, you wanted to point out that sequence is explicitly unimportant
davidb: is that a viable solution?
amy: at that point you fall into
which one is "second"
... we are suggesting that you return to the wsdl 1.1
heuristics
davidb: i don't think i was clear
enuf, the definition of MEP would have to refer to the implicit
labels
... and that is how it would be clear which message schema it
is refering to
<alewis> i think that it doesn't work, is all.
amy: i don't think u have a win.
It is just a label
... the idea of putting implicit labels suggests that we have a
property that suggests order
<dbooth> <operation ...>
<dbooth> <input /> # in
<dbooth> <input /> # in2
<dbooth> <input /> # in3
<dbooth> <output /> # out
<dbooth> <output /> # out2
<dbooth> </operation>
amy: too many tooling issues
dbooth: the point is that these would be THE message labels
<dbooth> The MEP would then have to refer to in, in2, in3, out, out2.
glen: the authors still need to put the right labels on each message
amy: it is lot easier to figure out what is wrong without implicit labeling
davidb: this is just a suggestion
tom: i don't think this solution helps much, not a bad idea, but does not resolve the issue
<kliu> +1 to tom
tom: I support leaving status quo
<asir> +1 to tom
davidb: does that address your concern, arthur?
arthur: no. it is not a syntax issue, it is a component model issue
glen: there has to be at least a way to support the MEPs that we define
arthur: but there isn't an MEP
that has 2 or more messages in the same direction
... give me an example of that
glen: what about fault?
<TomJ> IBMs point is valid (unused stuff), but I don't believe it is compelling enough to remove messageLabel.
arthur: fault is not a message
glen: then why is in-only and robust-in different?
arthur: the point is that we
allow the flexibility to allow more then one message in a given
direction but we lack the existance proof for it
... and we have evidence of wsdl 1.1
glen: we want to use it, for example, multiple in-messages (optional) and an out-message
arthur: all I'm asking is an example
jonathan: we can do this as CR existance criterion
glen: we are just starting to implement our wsdl 2.0 infrastructure why do you want to prevent this
davidb: is the message schema the same for all the in-messages?
glen: don't know
[more discussion on whether such a thing is useful or not]
<kliu> I don't see why we want to limit people from defining MEPs with mulitple messages in one direction
davidb: would we be removing the extensiblity of the spec. is that right?
jonathan: no
... u can still write such meps, but u have to come up with a
mechanism to do this
kevin: does the CR criteria apply only to this or others too
jonathan: the proposal is to make this functionality an exit criteria
kevin: we have many optional features -- this priciple can be applied to all of those
jonathan: absolutely
... we need to have a whole collection
kevin: if we have a collection then I don't have an objection
PROPOSAL: to close issue LC61c with no change and give chair an action to start a list for exit criteria and include the message lable property as requiring at least one use in a public spec
jonathan: if we don't have an
exit criteria then we will have to come back and reopen this.
We may want to add an implementation requirement
... any objections
no objections
RESOLUTION: close LC61c with the above proposal
<kliu> I would prefer close with no action, but can live with the proposal
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75i
PROPOSAL: to accept the issue raiser's proposal -- remove infault and outfault
Tony: could you use this as SNMP trapping?
no objections to the proposal
RESOLUTION: issue LC75i is closed with the proposal above
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75k
jonathan: i believe we did this knowing that soap allowed this
[discussion on how one could do this in WSDL currently]
arthur: we made the simple case
simple by doing this
... perhaps this is a comment against our soap binding
jonathan: i don't see this as soap specific
arthur: yes, it isn't. But we
decided not to invent another type system
... if you want more flexibility you do that in the
binding
... it makes more sense to modify our soap binding, the issue
raiser is complaining about SOAP
... in the http case, is it a multi-part response?
... so it is really a binding issue
jonathan: is anyone interested enuf to put forward a proposal as to how to solve this problem in the binding
<kliu> ws-i BP has similar restriction - only one part for doc/literal binding
<asir> why is this a binding issue, rather than a Part 1 issue?
[discussion of why XMLP allowed multiple elements inside the soap:body]
tom: Proposal is to close the issue with no action as WS-I has indicated a single element in soap body and we run the risk of being profiled again
jonathan: don't agree with the
rationale
... if you want to put in extension do it in the binding
<Marsh> Jonathan: Alternate proposal: Close the issue by noting that this can be done by extending the binding, industry trend away from a single child makes us reluctant to support it at this time in our development.
glen: +1
<kliu> ok with both proposal, let's close it
no objection to the alternate proposal
RESOLUTION: close issue LC75k with the alternate proposal
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LCLC75l
<asir> +1 to editorial !!
<alewis> agree with commenter: modify 2-13; editorial.
<asir> I agree with Jeff too
PROPOSAL: close the issue by making the message label property of the binding message reference component required AND substituting an error for empty in the text in the message label mapping in table 2-13
no objections to the proposal
<asir> yeh, that closes LC 103 too
RESOLUTION: close issue LC103 and LC75l with the proposal
<asir> title of 103 is "{message label} property of Binding Message Reference Component Should be REQUIRED"
jonathan: we have an offer from SAP to hold a joint meeting in summer in Berlin
Markn: the time for the f2f
depends on what happens wrt to our schedule
... could be late april/early may
jonathan: we have lot of work so
don't want to strech it too much between f2f
... ac meeting in south of france in 1st week of june
... would be convenient to have it before or after the ac
meeting
... also got an offer from jean-jacques to hold a meeting in
Reenes
<jjm> s/Reenes/Rennes/ ;-)
--- adjourned ---