See also: IRC log
<Jonathan> ACTION: Jonathan to fix transferCodings - add control group. [recorded in http://www.w3.org/2006/12/14-ws-desc-minutes.html#action01]
<scribe> scribe: JacekK
RESOLUTION: minutes approved
-------------------------------------------------------------------- 3. Review of Action items [.1]. [Interop] ? 2006-11-30: [interop] John Kaputin to create a test case with "required=false". [WG] CONTINUE 2006-09-21: Jonathan to check periodically that SPARQL has added schemaLocation. ? 2006-10-12: pdowney to review the Schema WG note on versioning in 1.1. DONE [.3] 2006-11-30: Jonathan will propose a plan for publishing component model interchange format as a note. DONE [.4] 2006-11-30: Charlton to review WS-Policy LC. DONE [.5] 2006-12-07: Asir to open a WS-Policy issue and link it with CR80. DONE [.6] 2006-12-07: Arthur to look at CR098. DONE [.7] 2006-12-07: Arthur to look at CR099. DONE [.8] 2006-12-07: Amy to write a proposal for CR108. Current Editorial Action Items Note: Editorial AIs associated with LC issues recorded at [.2]. [.1] http://www.w3.org/2002/ws/desc/#actions [.2] http://www.w3.org/2002/ws/desc/5/cr-issues/actions_owner.html [.3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-interchange-f ormat.xml?content-type=application/xml [.4] http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0055.html [.5] http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0051.html [.6] http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0052.html [.7] http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0053.html [.8] http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0033.html
Jonathan: we shouldn't spend time on component model interchange document before January
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
Jonathan: is there something we can do now to move this topic ahead?
jjm: probably disregard my latest
... 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
... "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
... 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
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
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
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
... 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
... 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
... 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]
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
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
... 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
Jonathan reads the issue
Jonathan: should robust in-only bind to a specific HTTP code?
plh: I'd say 202, empty
... 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
... 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
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]
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]
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
RESOLUTION: import the query separator and query separator default properties to the SOAP binding