16:19:13 <RRSAgent> RRSAgent has joined #ws-desc
16:19:14 <RRSAgent> logging to http://www.w3.org/2006/12/21-ws-desc-irc
16:19:27 <scribe> ACTION: Jonathan to reference the Versioning document in the WSDL Primer
16:19:36 <scribe> ACTION: Jonathan to respond to Ashok Malhotra/WS-Policy on WSDL 1.1 component indicators
16:20:26 <scribe> 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
16:20:40 <scribe> jonathan: MTOM description - skip over this for today's telcon
16:21:27 <scribe> monica: Comment - have you considered if more WG members were present so as to publish comments on the MTOM policy to the WSP WG>
16:21:37 <scribe> s/>/?/
16:22:13 <scribe> monica: Interested in the area of simplified policies
16:22:53 <scribe> jonathan: Am interested in whether profiled policies is the way to go
16:23:07 <scribe> monica: Is this Canon's or a broader domain concern?
16:24:08 <scribe> 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
16:24:48 <scribe> jonathan: issues
16:24:54 <scribe> jonathan: CR108
16:25:18 <scribe> jonathan: amy and roberto sent emails indicating no equivalence
16:25:28 <scribe> jonathan: sent an email with his equiv analysis
16:26:46 <scribe> arthur: roberto showed we don't have a constraint so that assertion 0014 implies 0006
16:27:36 <scribe> arthur: 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
16:28:10 <scribe> arthur: should explicitly place document level constraints; with this i'm fine with eliminating 006
16:28:49 <scribe> scribe: charlton
16:30:01 <scribe> amy: I think we're close to similar things, with different vocabularies :-); I'm comfortable with 006 being removed
16:30:35 <scribe> arthur: I want to add four new assertions - w.r.t. the placeholder message for direction and type
16:30:45 <scribe> amy: Why doesn't 2.10.1 cover that?
16:30:57 <scribe> arthur: Addresses it at the component model
16:31:09 <scribe> amy: You will eventually fail in any case
16:31:40 <scribe> 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
16:32:51 <scribe> arthur: 2.10 only discussues bindings and interfaces
16:33:40 <scribe> 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.
16:33:49 <scribe> arthur: Not saying change 2.10 at XML level
16:34:28 <scribe> amy: Not suggesting that - but what happens is that will have an error if the binding doesn't find something that it matches
16:34:39 <scribe> amy: So what do we gain from adding the 4 assertions?
16:34:48 <scribe> arthur: These 4 are document level assertions
16:35:19 <scribe> arthur: Input and output don't have direct correspondents at component level - we can check them at the document level
16:35:39 <scribe> jonathan: New assertions - if we add them at the interface, we're ok?
16:35:56 <scribe> arthur: Yes
16:36:33 <scribe> arthur: 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
16:37:08 <scribe> amy: Because it happens in the binding, yes. But my question is I don't see why assertions on the markup are not redundant
16:37:19 <scribe> arthur: Markup assertions can violate component model assertions
16:37:38 <scribe> amy: But the component assertions will catch these [eventually]
16:38:18 <scribe> amy: I don't think that these additonal 4 assertions will change the set of documents that will fail
16:38:49 <scribe> arthur: You can't even evaluate 2.10 until you construct the component model
16:40:29 <Zakim> -Paul_Downey
16:40:46 <pauld> pauld has left #ws-desc
16:41:17 <scribe> amy: I understand what Arthur want's but don't think the 4 assertions will achieve that
16:45:05 <Zakim> -Gilbert_Pilz
16:45:28 <scribe> arthur: Ok, I do think they are redundant - but the message you get may be hard to understand, so these assertions are general
16:46:05 <scribe> arthur: W/o message label, would be 0012 - but with other 4 assertions would get a clearer error message for each case
16:46:42 <scribe> amy: Should we ask Lawrence Mandel for some feedback on the 4 assertions?
16:47:05 <scribe> amy: We have agreed to remove assertion 006 (and assertion 004)
16:47:09 <scribe> jonathan: Yes
16:47:39 <Zakim> +Gilbert_Pilz
16:47:47 <scribe> arthur: If only one message label in each direction, don't need to specify it.... 
16:47:57 <gpilz> gpilz has joined #ws-desc
16:48:18 <scribe> amy: I don't think there's as big an issue at it seems - if we can get by without adding assertions
16:48:47 <scribe> jonathan: Should we add assertions that, although providing a better error message, are effectively duplicates?
16:49:23 <scribe> amy: If we didn't add these 4 assertions, would there still be a violation in some way>
16:49:28 <scribe> s/>/?/
16:49:48 <scribe> arthur: Some assertions don't even make sense if others are not satisfied - some are pre-conditions for others
16:50:13 <scribe> arthur: Pre-supposition of assertions - implicit pre-conditions
16:50:35 <scribe> amy: Agreed - ideally in my opinion the spec w/b such that an error would cause one and only one assertion to fail
16:50:45 <scribe> jonathan: Do we need another proposal for these assertions with more detail>
16:50:48 <scribe> s/>/?/
16:52:09 <scribe> arthur: You can take my note as a recommendation to add the 4 new assertions
16:52:37 <scribe> arthur: Would prefer clear error messages that map to something in the WSDL spec when writing a doc
16:54:00 <scribe> jonathan: Let's see if we can close CR108 by removing assertions 006 and 004
16:54:27 <scribe> jonathan: Would like to raise a new issue on adding Arthur's 4 new assertions - start email thread on this discussion
16:54:51 <scribe> jonathan: No objections
16:55:15 <scribe> Resolution for CR008 - remove assertions 006 and 004
16:55:36 <scribe> ACTION: Jonathan to raise new issue adding 4 new assertions as per Arthur's note
16:56:41 <scribe> 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)
16:58:18 <scribe> TOPIC: CR111
16:58:41 <scribe> jonathan: Issue is about whether we should say what the HTTP return code is for in-only and robust in-only cases
16:58:59 <scribe> jonathan: Proposal from last week: 202 for in-only and 204 for robust-in-only
16:59:17 <scribe> jonathan: plh checked with XMLP WG to see if they had a visceral reaction - they had none
16:59:46 <scribe> jonathan: Any reason anyone would object to using 202/204. 
17:00:10 <scribe> arthur: Think we need this
17:00:13 <scribe> charlton: Don't see a problem with it
17:00:22 <scribe> jonathan: Any objections to adding this? 
17:00:28 <scribe> None
17:00:59 <scribe> Resolution: Accept proposal to use 202 and 204 for in-only and robust in-only MEPs in HTTP binding
17:01:04 <scribe> TOPIC: CR114
17:02:21 <scribe> jonathan: What would you like to see added here, Youenn?
17:02:41 <scribe> youenn: Want mapping for robust in-only 
17:03:38 <scribe> (section 5.10.4)
17:04:33 <scribe> jonathan: You want a section 5.10.? mapping for in-only and robust in-only to SOAP MEPs
17:04:48 <scribe> jonathan: Can this be done - for in-only it makes no sense at all
17:04:56 <scribe> youenn: No, but for robust in-only yes
17:05:49 <scribe> youenn: Makes sense to map in-only and robust in-only MEPs to SOAP response MEP
17:06:06 <scribe> youenn: I would like this specified
17:06:34 <scribe> jonathan: Adding paragraph, for instance, to 5.10.4.1 to talk about in-only and robust in-only
17:06:48 <scribe> jonathan: Would hope this w/b straightforward
17:07:20 <scribe> jonathan: Add desc how to bind in-only and robust in-only WSDL MEPs to SOAP response MEP, taking advantage of 202 in PER
17:08:28 <scribe> jonathan: Can we close the issue today?
17:09:12 <scribe> Resolution: Close CR114 as per Youenn's proposal
17:09:18 <scribe> TOPIC: CR115
17:09:50 <scribe> http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR115
17:10:10 <scribe> arthur: Looks fine
17:10:38 <scribe> arthur: 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
17:11:42 <scribe> jonathan: In other words, the target namespaces must match
17:12:09 <scribe> jonathan: Proposal to adopt Lawrence Mandel's resolution
17:12:19 <scribe> No objections
17:12:36 <scribe> Resolution: Close CR115 with Lawrence Mandel's proposal
17:12:41 <scribe> TOPIC: CR116
17:12:57 <scribe> jonathan: Constructing request IRI - HTTP location template
17:13:38 <scribe> http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR116
17:14:23 <scribe> arthur: We shouldn't recycle the list or throw a runtime error
17:14:42 <scribe> phillipe: No value m/b diff from empty string
17:15:46 <scribe> arthur: prefer empty string option
17:16:55 <scribe> arthur: That's how http works - if have form, input field, and no value - it shows up as an empty string
17:17:11 <scribe> phillipe: Don't like repeating value option
17:17:17 <scribe> arthur: Neither do i
17:17:34 <scribe> jonathan: And nice for us not to force runtime errors
17:18:54 <scribe> jonathan: 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
17:21:15 <scribe> arthur: Think a SHOULD for the schema w.r.t. elements and templates would be in order
17:21:27 <scribe> arthur: Best practise that things match
17:22:07 <scribe> jonathan: Existing assertion is a runtime check
17:24:15 <scribe> arthur: Can check [otherwise]
17:27:21 <Jonathan> Proposal:
17:27:52 <Jonathan> 1) Rewrite HTTPSerialization-5073 to talk about types rather than instances.
17:28:05 <Jonathan> 2) Say each token SHOULD match something in the instance.
17:28:23 <Jonathan> 3) If there is no match, replace the token with the empty string.
17:28:45 <Jonathan> 4) Repeated tokens are replaced by repeated elements in order.
17:28:51 <youenn> s/to SOAP response MEP/to SOAP request response MEP
17:30:16 <Jonathan> 4) A token may appear more than once, in which case it is replaced by corresponding repeated elements in the instance.
17:30:58 <scribe> jonathan: Any objs to closing CR116 with this resolution
17:31:30 <Zakim> -Charlton_Barreto
17:31:32 <scribe> Resolution: Adopt Jonathan's Proposal as resolution to CR116
17:31:33 <Zakim> -Arthur
17:31:34 <Zakim> -TonyR
17:31:34 <Zakim> -Plh
17:31:37 <Zakim> -Canon
17:31:39 <Zakim> -Amelia_Lewis
17:31:39 <Jonathan> rrsagent, set log world
17:31:43 <Jonathan> rrsagent, draft minutes
17:31:43 <RRSAgent> I have made the request to generate http://www.w3.org/2006/12/21-ws-desc-minutes.html Jonathan
17:31:44 <scribe> Adjourn meeting
17:31:46 <Zakim> -Jonathan_Marsh
17:31:57 <alewis> alewis has left #ws-desc
17:32:04 <TonyR> TonyR has left #ws-desc
17:32:14 <Jonathan> Meeting: WS Description WG telcon
17:32:17 <Jonathan> Chair: Jonathan
17:32:19 <Jonathan> rrsagent, draft minutes
17:32:19 <RRSAgent> I have made the request to generate http://www.w3.org/2006/12/21-ws-desc-minutes.html Jonathan
17:32:32 <scribe> Scribe: Charlton
17:33:06 <scribe> zakim, who was on the call?
17:33:06 <Zakim> I don't understand your question, scribe.
17:33:13 <scribe> zakim, who's on the call?
17:33:13 <Zakim> On the phone I see Allen, m2, Gilbert_Pilz
17:33:29 <Jonathan> s/jonathan: CR108/Topic: CR108
17:34:09 <Jonathan> yes.  I'll add that.
17:34:12 <Jonathan> Thanks for scribing!
17:34:22 <scribe> you're welcome
17:34:56 <Zakim> -Allen
17:36:14 <charlton> s/Resolution:/RESOLUTION:/
17:36:55 <Zakim> -m2
17:41:55 <Zakim> disconnecting the lone participant, Gilbert_Pilz, in WS_DescWG()11:00AM
17:41:59 <Zakim> WS_DescWG()11:00AM has ended
17:42:01 <Zakim> Attendees were Gilbert_Pilz, Amelia_Lewis, Jonathan_Marsh, Plh, Charlton_Barreto, TonyR, Allen, Arthur, Paul_Downey, Canon, m2
17:46:04 <charltonb> charltonb has joined #ws-desc
18:02:59 <plh> plh has left #ws-desc
18:59:55 <Jonathan> rrsagent, draft minutes
18:59:55 <RRSAgent> I have made the request to generate http://www.w3.org/2006/12/21-ws-desc-minutes.html Jonathan
19:02:21 <Jonathan> i/ACTION: Jonathan to reference the/Topic: Approval of last week's minutes/
19:02:33 <Jonathan> i/ACTION: Jonathan to reference the/RESOLUTION: approved./
19:02:48 <Jonathan> i/ACTION: Jonathan to reference the/Topic: Action Item Review/
19:02:56 <Jonathan> i/ACTION: Jonathan to reference the/Topic: Administrivia/
19:03:11 <Jonathan> i/ACTION: Jonathan to reference the/pauld: schema 1.1 - compatibility between it and 1.0 - comment on making that more clear/
19:04:14 <Jonathan> rrsagent, draft minutes
19:04:14 <RRSAgent> I have made the request to generate http://www.w3.org/2006/12/21-ws-desc-minutes.html Jonathan
19:19:47 <Jonathan> Jonathan has joined #ws-desc
19:20:25 <Jonathan> s/Resolution:/RESOLUTION:/g
19:20:32 <Jonathan> RRSAgent, draft minutes
19:20:32 <RRSAgent> I have made the request to generate http://www.w3.org/2006/12/21-ws-desc-minutes.html Jonathan
20:41:51 <Zakim> Zakim has left #ws-desc
21:16:49 <Jonathan> rrsagent, bye
21:16:49 <RRSAgent> I see 3 open action items saved in http://www.w3.org/2006/12/21-ws-desc-actions.rdf :
21:16:49 <RRSAgent> ACTION: Jonathan to reference the Versioning document in the WSDL Primer [1]
21:16:49 <RRSAgent>   recorded in http://www.w3.org/2006/12/21-ws-desc-irc#T16-19-27
21:16:49 <RRSAgent> ACTION: Jonathan to respond to Ashok Malhotra/WS-Policy on WSDL 1.1 component indicators [2]
21:16:49 <RRSAgent>   recorded in http://www.w3.org/2006/12/21-ws-desc-irc#T16-19-36
21:16:49 <RRSAgent> ACTION: Jonathan to raise new issue adding 4 new assertions as per Arthur's note [3]
21:16:49 <RRSAgent>   recorded in http://www.w3.org/2006/12/21-ws-desc-irc#T16-55-36