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]
<Jonathan> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html
<scribe> scribe: JacekK
minutes: http://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/att-0032/20061207-ws-desc-minutes.html
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
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
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
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]
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
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
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]
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
<charltonb> +1
RESOLUTION: import the query separator and query separator default properties to the SOAP binding