WS Description WG telcon -- 14 Dec 2006

<Jonathan> ok

<Jonathan> ACTION: Jonathan to fix transferCodings - add control group. [recorded in http://www.w3.org/2006/12/14-ws-desc-minutes.html#action01]

<Jonathan> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html

<scribe> scribe: JacekK

approval of minutes

minutes: http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/att-0032/20061207-ws

-desc-minutes.html

RESOLUTION: minutes approved

action items

Jonathan: we shouldn't spend time on component model interchange document before January

Administrivia

Jonathan: membership of Vivek was corrected in WBS
... how many people won't make it next week?

regrets from Asir, JacekK, Roberto?

asir: please move WS-Policy comments to the telcon after next so I don't miss it

Jonathan: we can discuss it some, but let's postpone actualy resolutions
... thanks to charlton for submitting policy review, to be discussed next week and later
... databinding not yet reviewed, time until Jan 12

MTOM description

Jonathan: is there something we can do now to move this topic ahead?

jjm: probably disregard my latest message
... are we waiting for XMLP WG now?

Jonathan: haven't heard from Philippe in some time
... two possible approaches - 1) dual-purpose wsdl extension and policy assertion
... 2) how would it work with WSDL - direct extension, policy... does it introduce critical dependency on policy?
... it would be useful what Canon's high-level requirements are on this
... to get a feeling about whether it can be just a policy or something else

jjm: 1) we need MTOM in WSDL soon, would like to have interop
... or a way to upgrade later
... 2) we don't plan to support WS-Policy

asir: do you expect interop with a WSDL extension?

jjm: I don't know what's happening regarding MTOM in Policy

plh: XMLP will work on this as soon as they are allowed to do so, that's should be very soon
... "this" meaning MTOM assertion

<pauld> WS-Policy is in the W3C, has widespread support and as we have demonstrated has a simple syntax for applying assertions. What's not to like?

jjm: can we describe MTOM in WSDL using policy without having to support full policy?

Jonathan: there may be a profile of policy that would satisfy everyone

jjm: many embedded applications don't have resources for support for compositors

plh: simplest policy is <policy><mtom/></policy> - your impl can reject anything more complex

asir: it might be easy to look into the policy to see if mtom is there, then do it

plh: there'd be more complexity, but it could be usefully doable

Jonathan: let's move to issues

asir: if we're talking about a profile, would we need to do it formally, with a recharter?

plh: we don't need to document it formally here, maybe Canon could just put it in their docs as a limitation

jjm: I'd prefer a W3 spec to describe this

Jonathan: the primer showed it using f&p, but it can do the same using policy
... with options of showing full policy support, or just a subset for only MTOM

jjm: I was assuming we had a stronger (than primer) support for MTOM
... I discovered later that we didn't, only in the primer

<asir> Use of MTOM assertion + WSDL 20 is well described at http://www.w3.org/TR/2006/WD-ws-policy-attach-20061117/#wsdl20-example

Jonathan: so you would like WSDL to add description of MTOM sufficient to guarantee interop?

Arthur: does anything need to be done in policy spec to support this usage with MTOM?

asir: no, I don't think so

Arthur: the primer would be a good place for this then

Jonathan: jjm may not agree, but let's move on for now

plh: we should add an example, but that's all because other groups are specifying it normatively
... and we can mention a subset of policy, but not specify it
... would a policy with only the MTOM assertion in it solve your problem?

jjm: maybe not

plh: this would not only work for you, it would also work for others who do support policy

Jonathan: jjm should clarify the maybe not

Issue CR098

Jonathan: Types-1300002 doesn't seem to be an assertion

Arthur: I agree, we should clean up the sentence and remove assertion mark up

Jonathan reads the poetry suggested by Arthur

RESOLUTION: accept Arthur's proposal

issue CR099

Jonathan: Types-1300003 doesn't seem to be an assertion
... similar problem here

Arthur: if a statement is not an assertion, I make it a note and remove uppercase keywords

RESOLUTION: accept Arthur's proposal as well

Issue CR108

Jonathan: two assertions seem (to lawrence) to be duplicate

Jonathan reads the spec poetry

Arthur: the two statements are logically equivalent - negating the first gives the second
... they have the same truth tables

Jonathan: one expresses a dependency, other co-constraint, same intent, first one seems easier to read

Arthur: I'd suggest a symmetrical wording

Jonathan: amy suggests to remove the last assertion
... it's not prohibited for a binding op to have an output if the interface op doesn't have it
... should MessageLabel-0014 be stricken?

alewis: it's not only duplicate, it's unreachable, you violate stuff much earlier trying to get there
... but only one should be removed, it's not an exact duplicate
... that's 0014
... the assertion in 2.10.1 says each binding message reference must uniquely refer to an interface msg ref

Arthur: if 0006 and 0014 are equivalent, both should be striken

alewis: they're not equivalent
... 0014 is subsumed by the one in 2.10.1
... we don't even have a test case because we don't have a suitable MEP

Arthur: they're the same

alewis: they're not

Arthur: are too!
... let's get this offline and compare our reasoning
... if they're equivalent, both should be removed

Roberto: we can first settle the equivalence, then we can see if we should remove both

alewis: there is the same pattern elsewhere as well

Jonathan: let's give an action to somebody to analyze this

<scribe> ACTION: Arthur to examine the equivalence of 0006 and 0014 [recorded in http://www.w3.org/2006/12/14-ws-desc-minutes.html#action02]

CR109

Jonathan: is the suggestion a good idea?

RESOLUTION: editors will add an assertion that when using SOAP 1.2 the fault code QName is constrained to the five values from the spec

CR110

Jonathan: arthur asks, what does it mean when cookies="true"?

Arthur: it's not good if cookies="true" just means service will send them but client may ignore them
... it would be better if we mandate something, e.g. that the client accept and support the cookies
... the property is required but binding says cookies MAY be indicated

Jonathan: let's say "every binding does indicate"

RESOLUTION: first part - we clarify that "true" means the service relies on cookies and client must understand them; second part change MAY indicate to indicates

CR111

Jonathan reads the issue

Jonathan: should robust in-only bind to a specific HTTP code?

plh: I'd say 202, empty response
... that's what SOAP does
... we can do the same thing

youenn: +1 for 202
... and it seems there's potential for other things we're missing

Jonathan: yes, are we sure this MEP is the only one that needs to be specified?

Arthur: should we consider 204 as well? 202 implies async, 204 implies action done, no return
... does the MEP imply async?
... 204 should be used for robust MEP, because it guarantees there's no fault coming up

Jonathan: we have two proposals, 202, and 204

plh: 202 for in-only is appropriate, you don't care what happens, 204 gives you more info than you request

Arthur: agree

plh: for robust, it seems it should be 204

youenn: maybe the code is app-dependent?

plh: if you get 202 from robust-in-only, you can't get the fault later if it occurs

JacekK: agrees with Arthur, for robust it should be 204

youenn: should we let XMLP know?

Jonathan: it seems we should do 202 for in-only, 204 for robust-in-only

<scribe> ACTION: plh to check with XMLP whether they should be interested in 204 as well [recorded in http://www.w3.org/2006/12/14-ws-desc-minutes.html#action03]

CR112

Jonathan: we're combining location with address prematurely in the spec
... if I don't have an endpoint and only binding (or multiple endpoints), we cannot compute the value of the property
... looks editorial
... no, looks substantial

TonyR: let's get a proposal from the editors

<scribe> ACTION: plh to come up with a more detailed proposal for CR112 if possible [recorded in http://www.w3.org/2006/12/14-ws-desc-minutes.html#action04]

CR113

youenn: we're missing properties in SOAP binding for reuse of HTTP binding

Arthur: why did we even allow different query separators?

Jonathan: best practice differs from real practice
... proposal: import the query separator properties to the SOAP binding as well

<charltonb> +1

RESOLUTION: import the query separator and query separator default properties to the SOAP binding

- DRAFT -

WS Description WG telcon

14 Dec 2006

Attendees

Contents