WS Description WG telcon -- 21 Dec 2006

Approval of last week's minutes

<inserted> RESOLUTION: approved.

Action Item Review

Administrivia

<inserted> pauld: schema 1.1 - compatibility between it and 1.0 - comment on making that more clear

<scribe> ACTION: Jonathan to reference the Versioning document in the WSDL Primer [recorded in http://www.w3.org/2006/12/21-ws-desc-minutes.html#action01]

<scribe> ACTION: Jonathan to respond to Ashok Malhotra/WS-Policy on WSDL 1.1 component indicators [recorded in http://www.w3.org/2006/12/21-ws-desc-minutes.html#action02]

jonathan: Note that I have a draft [proposal] w.r.t. this area - assume that we will publish this, but if you have any comments or feedback, please provide to the group
... MTOM description - skip over this for today's telcon

monica: Comment - have you considered if more WG members were present so as to publish comments on the MTOM policy to the WSP WG?
... Interested in the area of simplified policies

jonathan: Am interested in whether profiled policies is the way to go

monica: Is this Canon's or a broader domain concern?

jonathan: Plausible that one can impl a comformant policy process that is fairly straightforward - is MTOM in use, and do I support MTOM - is this tractable in a constrained device? If those two questions can be answered then I don't see the need for profiles
... issues

CR108

jonathan: amy and roberto sent emails indicating no equivalence
... sent an email with his equiv analysis

arthur: roberto showed we don't have a constraint so that assertion 0014 implies 0006
... with input element, must be at least one placeholder message for the input message, and with output element, must be at least one placeholder message for the output message
... should explicitly place document level constraints; with this i'm fine with eliminating 006

<scribe> scribe: charlton

amy: I think we're close to similar things, with different vocabularies :-); I'm comfortable with 006 being removed

arthur: I want to add four new assertions - w.r.t. the placeholder message for direction and type

amy: Why doesn't 2.10.1 cover that?

arthur: Addresses it at the component model

amy: You will eventually fail in any case

arthur: At binding level can't have multiple binding messages for a single interface message reference; I placed a counterexample where 2.10.1 would fail even though the assertions would pass
... 2.10 only discussues bindings and interfaces

amy: In 2.10.1, it is stated that interface message is require - must create the property - and must bind them uniquely per the assertion.

arthur: Not saying change 2.10 at XML level

amy: Not suggesting that - but what happens is that will have an error if the binding doesn't find something that it matches
... So what do we gain from adding the 4 assertions?

arthur: These 4 are document level assertions
... Input and output don't have direct correspondents at component level - we can check them at the document level

jonathan: New assertions - if we add them at the interface, we're ok?

arthur: Yes
... One input in the MEP - at the binding level, can put in two input elements - that would be fine w.r.t. constraint on message level attribute - but would violate 2.10.1

amy: Because it happens in the binding, yes. But my question is I don't see why assertions on the markup are not redundant

arthur: Markup assertions can violate component model assertions

amy: But the component assertions will catch these [eventually]
... I don't think that these additonal 4 assertions will change the set of documents that will fail

arthur: You can't even evaluate 2.10 until you construct the component model

amy: I understand what Arthur want's but don't think the 4 assertions will achieve that

arthur: Ok, I do think they are redundant - but the message you get may be hard to understand, so these assertions are general
... W/o message label, would be 0012 - but with other 4 assertions would get a clearer error message for each case

amy: Should we ask Lawrence Mandel for some feedback on the 4 assertions?
... We have agreed to remove assertion 006 (and assertion 004)

jonathan: Yes

arthur: If only one message label in each direction, don't need to specify it....

amy: I don't think there's as big an issue at it seems - if we can get by without adding assertions

jonathan: Should we add assertions that, although providing a better error message, are effectively duplicates?

amy: If we didn't add these 4 assertions, would there still be a violation in some way?

arthur: Some assertions don't even make sense if others are not satisfied - some are pre-conditions for others
... Pre-supposition of assertions - implicit pre-conditions

amy: Agreed - ideally in my opinion the spec w/b such that an error would cause one and only one assertion to fail

jonathan: Do we need another proposal for these assertions with more detail?

arthur: You can take my note as a recommendation to add the 4 new assertions
... Would prefer clear error messages that map to something in the WSDL spec when writing a doc

jonathan: Let's see if we can close CR108 by removing assertions 006 and 004
... Would like to raise a new issue on adding Arthur's 4 new assertions - start email thread on this discussion
... No objections

Resolution for CR008 - remove assertions 006 and 004

<scribe> ACTION: Jonathan to raise new issue adding 4 new assertions as per Arthur's note [recorded in http://www.w3.org/2006/12/21-ws-desc-minutes.html#action03]

jonathan: Proposal - in-only would raise a 202, robust in-only a 204. XMLP did not have a strong opinion on this for HTTP (although they are definitely not doing this for SOAP)

CR111

jonathan: Issue is about whether we should say what the HTTP return code is for in-only and robust in-only cases
... Proposal from last week: 202 for in-only and 204 for robust-in-only
... plh checked with XMLP WG to see if they had a visceral reaction - they had none
... Any reason anyone would object to using 202/204.

arthur: Think we need this

charlton: Don't see a problem with it

jonathan: Any objections to adding this?

None

RESOLUTION: Accept proposal to use 202 and 204 for in-only and robust in-only MEPs in HTTP binding

CR114

jonathan: What would you like to see added here, Youenn?

youenn: Want mapping for robust in-only

(section 5.10.4)

jonathan: You want a section 5.10.? mapping for in-only and robust in-only to SOAP MEPs
... Can this be done - for in-only it makes no sense at all

youenn: No, but for robust in-only yes
... Makes sense to map in-only and robust in-only MEPs to SOAP response MEP
... I would like this specified

jonathan: Adding paragraph, for instance, to 5.10.4.1 to talk about in-only and robust in-only
... Would hope this w/b straightforward
... Add desc how to bind in-only and robust in-only WSDL MEPs to SOAP request response MEP, taking advantage of 202 in PER
... Can we close the issue today?

RESOLUTION: Close CR114 as per Youenn's proposal

CR115

http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR115

arthur: Looks fine
... Think point is that there are two independent assertions, but this is an ex of how one assertion only makes sense when the other is satisfied

jonathan: In other words, the target namespaces must match
... Proposal to adopt Lawrence Mandel's resolution

No objections

RESOLUTION: Close CR115 with Lawrence Mandel's proposal

CR116

jonathan: Constructing request IRI - HTTP location template

http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR116

arthur: We shouldn't recycle the list or throw a runtime error

phillipe: No value m/b diff from empty string

arthur: prefer empty string option
... That's how http works - if have form, input field, and no value - it shows up as an empty string

phillipe: Don't like repeating value option

arthur: Neither do i

jonathan: And nice for us not to force runtime errors
... Proposal - should have schema s/t have enough elements to address token names in template, but if not, use empty string for any elements that remain

arthur: Think a SHOULD for the schema w.r.t. elements and templates would be in order
... Best practise that things match

jonathan: Existing assertion is a runtime check

arthur: Can check [otherwise]

<Jonathan> Proposal:

<Jonathan> 1) Rewrite HTTPSerialization-5073 to talk about types rather than instances.

<Jonathan> 2) Say each token SHOULD match something in the instance.

<Jonathan> 3) If there is no match, replace the token with the empty string.

<Jonathan> 4) Repeated tokens are replaced by repeated elements in order.

<Jonathan> 4) A token may appear more than once, in which case it is replaced by corresponding repeated elements in the instance.

jonathan: Any objs to closing CR116 with this resolution

RESOLUTION: Adopt Jonathan's Proposal as resolution to CR116

Adjourn meeting

<scribe> Scribe: Charlton

<Jonathan> yes. I'll add that.

<Jonathan> Thanks for scribing!

you're welcome

- DRAFT -

WS Description WG telcon

21 Dec 2006

Attendees

Contents