Web Services Description F2F (continued) -- 21 Jan 2005

<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

LC24: "ad:mustUnderstand"

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

issue LC53

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

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.

Message and fault issues

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

issue LC61c

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> <input /> # in

<dbooth> <input /> # in2

<dbooth> <input /> # in3

<dbooth> <output /> # out

<dbooth> <output /> # out2

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

issue LC75i

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

issue LC75k

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

issue LC75l

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"

Upcoming F2F Meetings

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 ---

- DRAFT -

Web Services Description F2F (continued)

21 Jan 2005

Attendees

Contents