See also: IRC log
RESOLUTION: approved.
[Interop]
? 2006-11-30: [interop] John Kaputin to create a test case
with "required=false".
? 2006-12-14: [interop] Jonathan to fix transferCodings -
add control group
[WG]
DONE [.3] 2006-10-12: pdowney to review the Schema WG note on versioning
in 1.1.
DONE 2006-12-14: Arthur to examine the equivalence of 0006 and 0014
DONE 2006-12-14: plh to check with XMLP whether they should be
interested in 204 as well
? 2006-12-14: plh to come up with a more detailed proposal for
CR112 if possible
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://lists.w3.org/Archives/Public/www-ws-desc/2006Dec/0062.html
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]
jonathan: Arthur to examine equiv of 0006 and 0014 - marked as Done
jonathan: Phillipe to check with XMLP regarding 202/204 return from [robust] one-way requests
philippe: Don't think this affects HTTP binding, no reason from XMLP group to not use 202/204 as indicated in last week's call
jonathan: Administrivia: No telcon next week, resume 1st week of Jan
jonathan: Postpone databinding review until Jan 04
jonathan: WSDL 1.1 component indicators - request from Ashok Malhotra to remove direction indicators from message designators, Amy responded that can't do this in WSDL 2
jonathan: Express a pref on WSDL 1.1. component indicators to keep them consistent with WSDL 2 even though there is redundant info, or to go with the short form even though inconsistent with WSDL 2 indicators
arthur: Add more MEPs to WSDL 1.1?
jonathan: No concept of extended MEPs in WSDL 1.1
arthur: No preference either way; pointed out that the direction indicators are needed for WSDL 2
amy: Point out that if they want compat with WSDL 2, should keep them consistent
charlton: +1
<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
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)
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
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
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
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