IRC log of ws-addr on 2006-03-03

Timestamps are in UTC.

07:47:52 [RRSAgent]: RRSAgent has joined #ws-addr
07:47:52 [RRSAgent]: logging to http://www.w3.org/2006/03/03-ws-addr-irc
07:50:25 [bob]: Meeting: Web Services Addresing WG face to face meeting
07:50:38 [bob]: Chair: Bob Freund
07:59:06 [bob]: Agenda: http://www.w3.org/mid/7D5D3FDA429F4D469ADF210408D6245A0390BD@jeeves.freunds.com
08:06:51 [pauld]: pauld has joined #ws-addr
08:08:25 [dhull]: dhull has joined #ws-addr
08:09:51 [TRutt]: TRutt has joined #ws-addr
08:10:06 [TonyR]: TonyR has joined #ws-addr
08:10:09 [hugo]: hugo has joined #ws-addr
08:10:18 [TRutt]: scribe:TRutt
08:10:34 [TRutt]: scribe:TRutt
08:11:06 [TRutt]: TOPIC:FaultCodes
08:13:08 [TRutt]: Jonathan stated that Microsoft has already implemented several of the FaultCodes that we agreed to eliminate on Thursday.
08:16:09 [TRutt]: Agreed to put back DestUnreachable, ActionNotSupported, and EndpointNotAvailable
08:16:36 [TRutt]: Katy asked if these had to be implemented to claim conformance
08:16:59 [TRutt]: Bob F stated that they do not have a MUST constraint anywhere in the spec,
08:17:12 [dorchard]: dorchard has joined #ws-addr
08:20:18 [TRutt]: David: Implementation of these faults are optional (for the last three we are adding back in)
08:21:08 [Jonathan]: Jonathan has joined #ws-addr
08:21:26 [TRutt]: Agreed to add this note to the descriptions of each of these three faults
08:22:40 [TRutt]: RESOLUTION: Insert after the description of "destination unreachable" action not supported" and endpoint not availalble, the following "implementation of this fault is optional."
08:23:05 [TRutt]: TOPIC: Interop Testing Report
08:23:06 [Katy]: Katy has joined #ws-addr
08:23:40 [Jonathan]: http://www.w3.org/2002/ws/addr/testsuite/report/
08:24:49 [TRutt]: Paul: we lost the asynchronous tests from SUN. The test implementations need more work.
08:25:28 [pauld]: as does the report
08:25:58 [pauld]: and collection of logs which are dip feeding in from various sources asynchronously
08:26:20 [TRutt]: Jonathan: microsoft/IBM and IBM/microsoft, IBM/IBM, and microsoft/Microsoft are all OK.
08:26:40 [uyalcina]: uyalcina has joined #ws-addr
08:27:06 [TRutt]: Marc H: there could be a problem with the logs, our developers state the implementation is correct.
08:28:02 [daveo]: daveo has joined #ws-addr
08:28:16 [hugo]: Zakim, who's on the phone?
08:28:16 [Zakim]: sorry, hugo, I don't know what conference this is
08:28:17 [Zakim]: On IRC I see daveo, uyalcina, Katy, Jonathan, dorchard, hugo, TonyR, TRutt, dhull, pauld, RRSAgent, Zakim, bob
08:28:25 [hugo]: Zakim, this will be WS_Addr
08:28:25 [Zakim]: ok, hugo; I see WS_AddrWG(TP)3:00AM scheduled to start 28 minutes ago
08:28:31 [TRutt]: Paul: we could have problems with collecting the logs, or with generation of the report. Some of the "green" boxes could be wrongly idenfitied as well.
08:28:43 [TRutt]: Jonathan: I do not think we have fundamental issues.
08:29:50 [TRutt]: Jonathan: the biggest risk is that we do not have 4 complete implemenations.
08:30:42 [TRutt]: Glen: once we fix some of the AXIS problems, that could be fixed.
08:31:24 [TRutt]: Paul: we might have 5 implemenations, but some of the features may have a different set of 4 implementations.
08:31:39 [TRutt]: s/menations/mentations/
08:32:42 [TRutt]: Bob F: are there any changes which need to be made to the spec.
08:33:18 [TRutt]: Paul: I do believe we have found the problems in the text already, and we have already reported those to the group.
08:33:19 [yinleng]: yinleng has joined #ws-addr
08:33:37 [Zakim]: WS_AddrWG(TP)3:00AM has now started
08:33:45 [Zakim]: +David_Illsley
08:33:47 [Zakim]: -David_Illsley
08:33:48 [Zakim]: WS_AddrWG(TP)3:00AM has ended
08:33:49 [Zakim]: Attendees were David_Illsley
08:34:01 [TRutt]: Bob F: what remains is documentation of 4 interoperating implemtations for all of the test cases.
08:36:17 [TRutt]: Bob F: would be good to have the test documentation completed by March 13 WG teleconf.
08:37:10 [TRutt]: Hugo: intention to go to PR from the WG on March 13.
08:37:42 [Zakim]: WS_AddrWG(TP)3:00AM has now started
08:37:50 [Zakim]: +??P2
08:38:05 [yinleng]: zakim, ??P2 is me
08:38:05 [Zakim]: +yinleng; got it
08:38:51 [hugo]: Zakim, call TP_Iles_B
08:38:51 [Zakim]: ok, hugo; the call is being made
08:38:52 [Zakim]: +TP_Iles_B
08:39:03 [umit]: umit has joined #ws-addr
08:39:39 [Nilo]: Nilo has joined #ws-addr
08:40:26 [Jonathan]: q+ to close with no action
08:40:32 [TRutt]: TOPIC: Closure of remaining CR Issues
08:40:46 [bob]: ack jo
08:40:46 [Zakim]: Jonathan, you wanted to close with no action
08:41:13 [TRutt]: Bob F stated that the at risk feature for wsa:from has been stated by several groups as a feature that they have a use case for.
08:41:48 [TRutt]: Paul D: none of the implementations have used this feature.
08:42:09 [umit]: q+
08:42:58 [TRutt]: Paul D: My statement is incorrect. there are implementations which send wsa:From. We could add one test case to show that implemtatations can deal with it.
08:43:11 [TRutt]: Marc G: since its optional we need two implementations to send it.
08:43:15 [bob]: ack u
08:43:53 [dhull]: q+
08:44:32 [bob]: ack dh
08:44:52 [pauld]: notes that a test case could be 'don't bail on reception of a message with wsa:From' and then make sure three others interop with WSO2
08:45:04 [TRutt]: Umit: I recommend that we close this issue with no change. Even though there is no explicit fallback to use of wsa:from in the behaviour text for replies, some users have found a reason to use this.
08:45:15 [bob]: scribenick: TRutt
08:46:33 [TRutt]: Jonathan: the spec has the field, but does not say what to do.
08:47:50 [TRutt]: RESOLUTION: agreed to remove the "at risk" note from the CR text, and close the features at risk issue.
08:50:04 [TRutt]: Glen stated that the axis implementation can generate the wsa:from element, and can do so for testing purposes.
08:51:11 [TRutt]: Hugo: we should ensure that the complete implementations can all receive messages with all the optional features.
08:52:38 [TRutt]: Paul D: we should add a test case which has wsa:from with mustUnderstand=true.
08:54:50 [bob]: q?
08:55:06 [TRutt]: Jugo took the action to add the new test case for wsa:from generation with mustUnderstand=true
08:55:17 [TRutt]: s/Jugo/Hugo/
08:56:55 [TRutt]: TOPIC: CR2
08:59:17 [dhull]: q+
08:59:43 [TRutt]: Bob F: this is a posponed issue on [Details] for wsa:ActionMismatch Subsubcode)
09:00:58 [bob]: ack dh
09:03:56 [TRutt]: Dave H: add text to section 2.4 of soap binding- "This invalid addressing header fault MUST/SHOULD contain a problem action fault detail.
09:05:55 [TRutt]: Jonathan: I do not think we need to do this, given the existing text.
09:06:07 [TRutt]: RDSOLUTION: agreed to close CR2 with no action.
09:06:21 [TRutt]: s/RDSOLUTION/RESOLUTION/
09:11:46 [Zakim]: -yinleng
09:31:53 [hugo]: Zakim, who's on the phone?
09:31:53 [Zakim]: On the phone I see TP_Iles_B
09:31:57 [Zakim]: -TP_Iles_B
09:31:58 [Zakim]: WS_AddrWG(TP)3:00AM has ended
09:31:59 [Zakim]: Attendees were yinleng, TP_Iles_B
09:39:39 [jeffm]: jeffm has joined #ws-addr
09:39:52 [TRutt]: TOPIC: Dave Hull NEW ISSUE
09:39:54 [GlenD]: GlenD has joined #ws-addr
09:41:00 [anish]: anish has joined #ws-addr
09:41:55 [dhull]: http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Feb/0000.html
09:41:56 [bob]: This will be cr25
09:42:53 [TRutt]: tile of issue Use SOAP 1.2 properties where possible in describing SOAP 1.2 behavior.
09:43:57 [TRutt]: There were no objections to accepting the proposal, as an editorial change
09:44:18 [TRutt]: RESOLUTION: accept D Hull proposal for CR25 as editorial change
09:45:03 [TRutt]: TOPIC: Resolution challenge for CR3
09:47:31 [TRutt]: John Kemp sent concern in email http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Sep/0002
09:50:46 [TRutt]: Discussion led to conclusion that the original resolution was still acceptable to WG
09:52:29 [TRutt]: Jonathan: we can point to the existence of xml id exists.
09:52:55 [TRutt]: Jonathan: there is no local id attribute because xml:id exists.
09:53:17 [TRutt]: s/xml id exists/xml:id/
09:54:06 [TRutt]: RESOLUTION: Editor will provide additional text pointing to existence of xml:id
09:55:28 [TRutt]: Bob F: we need to have someone give a response to John Kemp
09:55:51 [TRutt]: Jonathan took action to prepare response to John Kemp on our reconsideration of CR3
09:57:11 [hugo]: RRSAgent, where am I?
09:57:11 [RRSAgent]: See http://www.w3.org/2006/03/03-ws-addr-irc#T09-57-11
09:57:19 [hugo]: RRSAgent, make log member
09:57:28 [TRutt]: TOPIC: Additional issues on Core
09:57:41 [TRutt]: Bob F asked if there are any additional issues on the Core spec.
09:57:50 [TRutt]: There were no further issues identified.
09:58:28 [TRutt]: Bob F: since we have no further issues, we have to produce the final version of the docs to review, and recommend for progression to PR.
09:58:40 [dorchard]: dorchard has joined #ws-addr
09:58:42 [TRutt]: Glen: when will the formal objections be reviewed and resolved.
09:59:31 [TRutt]: Mark N: the director has seen the formal objections, and has not sent feedback to the WG.
09:59:56 [TRutt]: Glen: what message did he send.
10:00:06 [TRutt]: Marc N: the messages was "yes you can go to CR"
10:01:42 [TRutt]: Hugo: until we are in recommendation, the director can say we have to resolve a particular formal objection. Officially we have to wait to see if he will assert on these objections, which he has already seen.
10:02:29 [TRutt]: Bob
10:03:14 [TRutt]: Bob F asked if any companies change their allignment with either of the formal objections. No company wished to change their allighment.
10:03:53 [TRutt]: Bob F asked the editors when they will have documents incorporating all resolutions.
10:04:06 [TRutt]: Marc H stated the documents would be ready by the end of the day.
10:05:02 [TRutt]: Bob F: I ask all members to review and send any coments before March 13. The intent is to vote to progress to PR at the March 13 meeting.
10:05:13 [TonyR]: s/allighment/alignment/
10:05:33 [TRutt]: Hugo: we should publish the soap 1.1 note at the same time as the PR.
10:07:00 [TRutt]: Bob F: Hugo will schedule a call with the Director after we vote to go to PR. The PR should be availalbe by the end of March, give a WG desicion on March 13.
10:07:46 [TRutt]: TOPIC: WSDL Doc Last Call issue LC09
10:09:04 [TRutt]: s/LC01/LC109/
10:09:16 [TRutt]: s/LC09/LC109/
10:11:33 [dhull]: q+
10:12:51 [TRutt]: s/desicion/decision/
10:13:11 [bob]: ack dh
10:15:04 [TRutt]: D hull: you can leave the faultTo empty if you have a replyTo present.
10:15:09 [umit]: q+
10:15:25 [TRutt]: Marc H: we need to clarify "either this or that"
10:16:15 [bob]: ack u
10:17:22 [TRutt]: Katy: the fault endpoint may be able to be derived by different means than presence in the request
10:17:39 [anish]: q+
10:17:42 [dhull]: q+
10:18:40 [bob]: ack an
10:20:07 [TRutt]: discussion ensued on table 5-5
10:20:36 [bob]: ack dh
10:21:06 [TRutt]: Marc H : suggest comgining reply endpoint and fault endpoint rows.
10:22:56 [TRutt]: Dave H: for Table 5.5, and Table 5.7 , and Table 5.2, we can change entroy for fault endpoint to Y with asterisk, with asterisk pointing to reference to section 3 of core.
10:23:13 [TRutt]: Anish: I prefer the merger of the two rows into "response endpoint".
10:23:40 [TRutt]: Call attention to section 3.4 of core regarding the fault endpoint semantics.
10:24:24 [TRutt]: Umit: I would rather not combine the two rows, I prefer Dave H proposal.
10:25:10 [TRutt]: Jonathan: concensus that one of reply endpoint or reply endpoint properties should appear in table 5.5.
10:25:27 [dhull]: q+
10:26:02 [bob]: ack dh
10:26:10 [Jonathan]: q+
10:26:17 [TonyR]: a/reply endpoint or reply/reply endpoint or fault/
10:26:25 [TonyR]: s/reply endpoint or reply/reply endpoint or fault/
10:26:28 [umit]: i would really like an example just like Anish. Combination of the specs need to be illustrated.
10:26:48 [bob]: ack j
10:27:10 [TRutt]: Dave H: it should be clarified that for robust in only the fault endpoint defaults to the reply endpoint.
10:28:53 [TRutt]: RESOLUTION: LC109 - at least one of reply endpoing or fault endpoint properties should appear in table 5.5
10:29:02 [TRutt]: s/endpoing/endpoint/
10:30:21 [TRutt]: s/appear in table 5.5/appear in table 5.5, with some indication of the co-constraints in the core spec/
10:31:15 [TRutt]: TOPIC: LC110 Should [fault endpoint] be prohibited in Robust in-only fault messages?
10:31:35 [anish]: q+
10:31:36 [TRutt]: Jonathan: this applies to table 5.6 and 5.8.
10:31:47 [TRutt]: Marc: table 5.6 was the first place it applied.
10:32:33 [Zakim]: WS_AddrWG(TP)3:00AM has now started
10:32:41 [Zakim]: +Mark_Little
10:32:45 [Zakim]: -Mark_Little
10:32:46 [Zakim]: WS_AddrWG(TP)3:00AM has ended
10:32:47 [Zakim]: Attendees were Mark_Little
10:32:58 [anish]: q?
10:33:01 [anish]: q+
10:33:33 [bob]: ack a
10:34:35 [TonyR]: q+
10:35:46 [TRutt]: Anish: what is good for reply is good for fault. We should not prohibit.
10:36:00 [bob]: ack t
10:36:32 [dhull]: q+
10:36:38 [TRutt]: Marc H: you canot give a fault to a fault message in soap.
10:37:07 [TRutt]: Tony R: all fault messages should have this note, not just the robust meps.
10:37:17 [pauld]: pauld has joined #ws-addr
10:37:38 [TRutt]: Dave H stated that we should not prohibit a fault to a fault.
10:38:01 [bob]: q?
10:38:08 [bob]: ack d
10:38:39 [dhull]: Just wondering whether it's our job to try to prohibit fault to a fault
10:38:46 [TRutt]: Tony R: in 5.2.3 we do not distinguish fault.
10:38:56 [TRutt]: Marc H: that is because it is an out.
10:39:08 [uyalcina]: uyalcina has joined #ws-addr
10:39:16 [TRutt]: RESOLUTION: LC110 agreed to be closed with no action.
10:39:39 [TRutt]: TOPIC: LC111 Section 3.1.1 clarity
10:40:01 [TRutt]: Bob F: this came from the WSDL 2 group.
10:40:34 [TRutt]: Hugo: the proposal is " Section 3.1.1 says:
10:40:34 [TRutt]: A property of the binding or endpoint named {addressing required}
10:40:34 [TRutt]: of type xs:boolean
10:40:34 [TRutt]
10:40:34 [TRutt]: should be phrased:
10:40:35 [TRutt]
10:40:37 [TRutt]: A property {addressing required} of type xs:boolean, to the
10:40:39 [TRutt]: Binding and Endpoint components
10:41:08 [TRutt]: Marc H: typically you put it on one place or another, not both
10:43:42 [TRutt]: RESOLUTION:LC110 resolved by accepting Hugo proposal
10:44:47 [TRutt]: s/110 resolved by/111 resolved by/
10:45:07 [TRutt]: TOPIC: LC112 Three states in two
10:46:25 [TRutt]: Hugo: we need to enable three cases. So, it should be made clear that {addressing required} is an optional property, whose value is "true" if wsaw:UsingAddressing is present and wsdl:required="true" is present, "false" if wsaw:UsingAddressing is present by wsdl:required is not equal to "true", and not present otherwise.
10:47:33 [bob]: q?
10:48:05 [TRutt]: Marc H: you either do or do not support addressing
10:50:38 [TRutt]: Tony R; addressing required is a mandatory boolean property.
10:51:40 [TonyR]: s/;/:/
10:52:13 [TRutt]: Anish: supported but not required forces a false value for "addressing required".
10:54:04 [TRutt]: Glen: we could have values "none" , required, and optional
10:54:13 [Jonathan]: q+
10:54:31 [TRutt]: Glen: having two values "required" and "optional" for this attribute.
10:54:45 [TRutt]: Jonathan summarized on the whiteboard what we have today.
10:56:43 [TRutt]: Jonathan: if using is on binding ti goes to both binding and endpoint. If using is on endpoint, it does not go to binding.
10:59:01 [TRutt]: Anish: I like having the values "required" and "optional" string enumerations.
10:59:41 [bob]: ack j
11:01:40 [TRutt]: Jonathan: we need to clarify 3.1.1 to say what we want. I do not like calling these "required" properties. if the existence of the property depends on the syntax of "using addressing"
11:02:10 [TRutt]: Tony: could be change "required" propety to "mandatory" property.
11:03:38 [TRutt]: Jonathan: exisence of using addressing on binding results in the required attribute to be true in binding.
11:03:58 [TRutt]: Anish: I do not understand what required means in this context.
11:09:31 [TRutt]: Katy: I challenge our earlier decision to put using addressing on endpoint
11:09:46 [uyalcina]: +1 to Katy
11:09:58 [anish]: i see the following columns for the table: 1) what's in the syntax, 2) does the processor recognize the extension, 3) wsdl:required value, 4) property present in the component model 5) value of the property in the component
11:10:52 [anish]: q+
11:11:34 [TRutt]: Jonathan: we can restrict the rules for bindings to be separate as for endpoint.
11:11:41 [bob]: ack a
11:13:50 [TRutt]: Anish proposed a table with 5 columns to express the semantics of using addressing to components.
11:15:30 [TRutt]: Jonathan: we need to remove the word required in the text, and to have a link from binding using addressing to binding component, and another link form endpoint using addressing to endpoint component.
11:16:39 [TRutt]: Group broke for lunch, to think about proper resolution for this lc issue
12:19:48 [yinleng]: yinleng has left #ws-addr
12:25:29 [Jonathan]: Jonathan has joined #ws-addr
12:27:47 [Jonathan]: Scribe: Jonathan
12:32:53 [TonyR]: TonyR has joined #ws-addr
12:34:35 [Jonathan]: Topic: Doc status update
12:34:41 [Jonathan]: Marc has checked in draft PR docs.
12:35:37 [uyalcina]: uyalcina has joined #ws-addr
12:35:39 [Jonathan]: Hugo will send a link to the snapshot to the WG.
12:36:08 [Jonathan]: Topic: lc112 continued
12:36:43 [Jonathan]: Bob: before lunch, Anish was thinking of a table. Jonathan was talking about a list of actions to resolve this issue.
12:37:38 [Jonathan]: Jonathan: Proposal:
12:38:04 [Jonathan]: ... Section 3.1.1: remove the word REQUIRED.
12:38:43 [Jonathan]: ... Describe that UsingAddressing on Binding annotates Binding component,
12:38:49 [Jonathan]: ... Describe that UsingAddressing on Endpoint annotates Endpoint component,
12:39:27 [Jonathan]: ... Possibly note that both values must be considered to determine whether Addressing is required for a particular message.
12:41:08 [Jonathan]: Anish: wsdl:required should not be used directly as the value of the property.
12:41:25 [Jonathan]: ... Might want a different value set for the property.
12:41:45 [Jonathan]: Glen: Would be nicer if the property existed or not, and then a separate property for the value.
12:42:09 [Jonathan]: ... If wsdl:required=true the value should be "required", if wsdl:required=false or not there, the value should be "optional".
12:42:27 [marc]: marc has joined #ws-addr
12:42:39 [Jonathan]: Tony: I like "addressing support" with the possible values of "required", "optional", "not known"/"not supported"
12:43:04 [Jonathan]: Anish: If the sytnax doesn't exist, you can still add the property.
12:43:20 [Jonathan]: ... The processor doesn't understand addressing, it won't be a property in the component model.
12:43:42 [Jonathan]: Jonathan: Be clear on component model - it's subtle.
12:44:16 [Jonathan]: Anish: Just change the naming of the property.
12:45:05 [Jonathan]: Bob: Regardless of the name, we have relationships. We need first to get relationship.
12:45:29 [Jonathan]: Tony: Want to allow the property appear even when there is no UsingAddressing extension.
12:45:47 [Jonathan]: Marc: Strange since you're telling people about yourself.
12:46:07 [Jonathan]: Tony: Want the third property to encompass that there is no addressing support here.
12:46:25 [Jonathan]: ... Not happy that absence implies it's supported.
12:47:17 [Jonathan]: ... How can I describe the service as not supporting addressing?>
12:47:33 [Jonathan]: Anish: We don't have such a marker.
12:47:46 [Jonathan]: Katy: Send a mustUnderstand="1" and get an error back.
12:47:56 [marc]: can't imagine a service ever saying wsa:addressing_support="unknown"
12:48:50 [Jonathan]: Tony: Thought that was what the tri-state is about.
12:49:04 [Jonathan]: Marc: It really only has two states. You either require it, or you don't.
12:49:22 [Jonathan]: Glen: It says, I support, or you have to use.
12:49:47 [Jonathan]: Marc: You don't have to tell I support. No new information provided.
12:50:06 [Jonathan]: Anish: We have three states in the value.
12:50:11 [Jonathan]: ... and presence.
12:50:29 [Jonathan]: marc: But if it's not present, it's not telling you that the service requires addressing.
12:50:46 [Jonathan]: Anish: Maybe the service isn't telling you but it is still required.,
12:50:50 [Jonathan]: (don't go there)
12:51:19 [Jonathan]: Glen: Difference between supported and required, and no indication.
12:51:29 [Jonathan]: ... If you understand addressing, you've gotta do it.
12:51:55 [anish]: q+
12:51:56 [Jonathan]: Marc: from the services perspective, you say UA=true when it's required.
12:52:11 [Jonathan]: ... when it's not, you put it in or not.
12:52:17 [Jonathan]: ... doesn't matter which.
12:52:39 [Jonathan]: Glen: How does that map to component model properties? Should be this addressing use property.
12:53:10 [bob]: ack a
12:53:24 [Jonathan]: Anish: If you require addressing, you must put UsingAddressing in the WSDL?
12:53:39 [Jonathan]: Marc: Not that far, just if you require it and you want an interoperable mechanism, use this one.
12:54:17 [Jonathan]: Umit: Provision in WSDL for this marker. We went through this well in WSDL.
12:55:22 [Jonathan]: Marc: My proposal is equivalent to {prop}="true" or not there. "false" doesn't give you any other information.
12:55:36 [Jonathan]: Glen: "false" tells you that you understood the marker at least.
12:56:08 [Jonathan]: ... If you don't support WS-A in the syntax, you shouldn't support it in the component model.
12:57:18 [NiloM]: NiloM has joined #ws-addr
12:57:28 [anish]: q+ to ask marc how his view would look like in terms of the component model
12:57:32 [Jonathan]: Jonathan: Thinks there is a difference. "False" means you can send the headers with mu and not expect a fault.
12:58:04 [Jonathan]: Glen: If you see this at the WSDL processing time, I will know whether I can send those headers or not. I might want to fault if the service doesn't delcare support for WS-A.
12:58:40 [Jonathan]: ... Tricky case is the optional one. We're overloading the marker to mean "process the WSDL" and "allows WS-A".
12:58:51 [Jonathan]: ... Once its in the component model, you're supposed to use WS-A at that point.
13:02:17 [Jonathan]: Tony: wsdl:required is different than addressing required.
13:02:43 [Jonathan]: Glen: Those concepts do get confused, both in SOAP and WSDL. We've been trying to overload that.
13:02:49 [bob]: ack ani
13:02:49 [Zakim]: anish, you wanted to ask marc how his view would look like in terms of the component model
13:02:50 [Jonathan]: Jonathan: Believe they collapse in practice.
13:03:12 [Jonathan]: Anish: Spec says if you put an annotation in and say wsdl:required, it may change the meaning of the element to which it's attached.
13:03:29 [Jonathan]: ... The qname we've defined means that you have to use addressing if required=true.
13:03:40 [Jonathan]: ... We define the meaning of the QName.
13:04:12 [Jonathan]: Glen: It says the meaning of [parent] might change when you understand [extension].
13:05:04 [Jonathan]: ... in practice it works out Ok. It's your choice to "understand" or not.
13:05:05 [marc]: q+ to talk about table 3.1
13:05:20 [Jonathan]: Anish: Can you translate how that translates to the component model.
13:05:29 [Jonathan]: Marc: Not up on cm speak.
13:05:49 [Jonathan]: Glen: If you don't understand the element you can't annotate the cm.
13:06:15 [Jonathan]: Umit: Provider puts the extension in. Client's perspective it contributes to the component model.
13:06:32 [Jonathan]: Glen: Choices are: understand the required extension or fault.
13:08:20 [anish]: it turns out that it is not us who are getting confused about overloading wsdl:required. The wsdl spec says the following:
13:08:22 [anish]: "A key purpose of an extension is to formally indicate (i.e., in a machine-processable way) that a particular feature or convention is supported or required."
13:10:04 [bob]: ack marc
13:10:04 [Zakim]: marc, you wanted to talk about table 3.1
13:10:11 [Jonathan]: (scribe loses a bit)
13:10:50 [Jonathan]: Marc: I'm willing to change my position. Spec says there are different requirements on an endpoint depending on whether they've put this in the WSDL or not.
13:11:13 [Jonathan]: ... Table 3-1. Key difference is MAPs in input message.
13:11:41 [Jonathan]: ... If you put it in, you have to accept addressing headers.
13:11:47 [pauld]: pauld has joined #ws-addr
13:11:59 [Jonathan]: ... Component model does need to reflect tri-state.
13:13:19 [Jonathan]: Bob: Tri-state issue, seems discussion revolves around whether this.
13:13:35 [Jonathan]: Katy: Required/supported/not-known are the states in the table.
13:14:30 [bob]: q?
13:15:14 [dorchard]: dorchard has joined #ws-addr
13:15:52 [Jonathan]: Glen: This is a problem with WSDL, I don't know what properties there are, what good does an abstract model do?
13:19:13 [Jonathan]: Jonathan: That's taken care of us by WSDL - read the Extensions part.
13:19:17 [Jonathan]: Bob: What's the proposal then?
13:19:34 [Jonathan]: Jonathan repeats. Essentially asking for a mapping of XML to component model.
13:20:06 [Jonathan]: Hugo: I proposed a mapping originally, Marc said it duplicated a lot of things.
13:20:19 [Jonathan]: ... Group said we can keep what we have.
13:20:30 [Jonathan]: Jonathan: Asserts that failed to be clear enough.
13:21:02 [Jonathan]: ... Would like to follow WSDL's style.
13:21:09 [Jonathan]: Bob: Fundamental objections?
13:21:47 [Jonathan]: Glen: Takes the WSDL required value rather than a different value.
13:21:59 [uyalcina]: uyalcina has joined #ws-addr
13:22:11 [Jonathan]: Anish: Call it {addressing} = "required
13:22:18 [Jonathan]: ..." / "optional"
13:22:27 [Jonathan]: Glen: call it {using addressing}
13:22:54 [Jonathan]: Jonathan: Proposal:
13:22:54 [Jonathan]: <Jonathan> ... Section 3.1.1: remove the word REQUIRED.
13:23:11 [Jonathan]: ... Add mapping of XML to component model
13:23:30 [Jonathan]: ... Possibly note that both properties must be consulted.
13:24:21 [Jonathan]: ... Change property name to {addressing}, values "required" / "optional"
13:24:34 [Jonathan]: Glen: Namespace properties?
13:26:07 [vikas]: vikas has joined #ws-addr
13:26:14 [vikas]: vikas has left #ws-addr
13:26:18 [Jonathan]: Jonathan: Didn't namespace the core WSDL properties. No framework for doing that.
13:26:38 [Jonathan]: Bob: Accept the proposal?
13:26:51 [Jonathan]: Katy: Looking at 3.2.1, might be impacts there.
13:28:00 [vikas]: vikas has joined #ws-addr
13:29:19 [Jonathan]: Marc: Needs more editorial direction.
13:29:26 [Jonathan]: Hugo: I'll draft some text.
13:30:03 [Jonathan]: ACTION: Hugo to draft mapping to CM of UsingAddressing.
13:30:59 [Jonathan]: RESOLUTION: Proposal (see above) accepted as resolution of lc112.
13:31:51 [Jonathan]: ... and equivalent editorial changes to 3.2.1.
13:32:09 [Jonathan]: ACTION 1=Hugo to draft mapping of CM to UsingAddressing and Anonymous
13:32:25 [Jonathan]: Topic: lc113 Section 3.3. clarity
13:33:12 [Jonathan]: ACTION 1=Hugo to draft mapping of CM to UsingAddressing and Anonymous, and Action
13:33:16 [Jonathan]: http://www.w3.org/2002/ws/addr/lc-issues/#lc113
13:34:11 [Jonathan]: Hugo: This section should be translated into WSDL 2.0 lingo (CM instead of XML)
13:34:51 [Jonathan]: ... Also not too clear on where it is allowed, have to chase references to intersect where UsingAddressing and soap:module are both allowed.
13:35:04 [Jonathan]: ... We should do the math for our readers. The intersection is the Binding component.
13:35:30 [Jonathan]: Glen: Not on endpoint?
13:35:43 [Jonathan]: ... Didn't we fix that at some point?
13:35:53 [Jonathan]: Hugo checks.
13:36:22 [Jonathan]: Glen: Need separate bindings for differnet module combinations? Too bad.
13:36:35 [Jonathan]: Bob: Objections?
13:37:50 [Jonathan]: Umit: UsingAddressing and soap:module have different expressive powers?
13:38:44 [Jonathan]: Glen: Researching a WSDL issue, we need soap:module at endpoint level.
13:40:09 [Jonathan]: Umit: Doesn't like this at the endpoint. Would rather we removed UsingAddressing at the endpoint.
13:40:34 [Jonathan]: Proposal acceptable as it stands?
13:40:46 [Jonathan]: s/Proposal/Bob: Proposal/
13:41:30 [Jonathan]: Umit: Need to check editorially that we don't imply UA and module are equivalent.
13:41:49 [Jonathan]: Glen: Equivalent semantics, but not equivalent places you can put it.
13:42:00 [Jonathan]: RESOLUTION: lc113 closed by accepting Hugo
13:42:23 [Jonathan]: RESOLUTION: lc113 closed by accepting Hugo's proposal, plus editorial check that we don't imply UA and module are completely equivalent.
13:42:50 [Jonathan]: Topic: lc114 Typos
13:43:05 [Jonathan]: RESOLUTION: Fix typos.
13:43:26 [Jonathan]: RESOLUTION: lc114 closed by fixing typos.
13:43:48 [Jonathan]: Topic: lc115
13:44:43 [Jonathan]: RESOLUTION: lc115 closed by accepting fix.
13:44:49 [bob]: bob has joined #ws-addr
13:45:22 [Jonathan]: Topic: lc116 use of wsa:ReferenceParameters
13:45:38 [Jonathan]: Bob: Doesn't say how this extension affects the WSDL 2.0 CM.
13:46:43 [Jonathan]: Jonathan: Let's do it.
13:46:52 [Jonathan]: ... property is a list of elements.
13:47:21 [Jonathan]: Anish: What about attributes on the wsa:ReferenceParameters element? Are they lost?
13:47:40 [Jonathan]: ... Isn't there a type for reference parameters already?
13:49:51 [Jonathan]: ... So use the same type as the [reference properties] property in 2.1 of Core.
13:50:36 [Jonathan]: Umit: We discussed it, we just forgot?
13:51:23 [Jonathan]: s/properties/parameters/
13:51:53 [uyalcina]: uyalcina has joined #ws-addr
13:52:10 [Jonathan]: Proposal: Add a {reference parameters} property to the WSDL 2.0 component model, with the same type as the [reference parameters] property in Core 2.1
13:53:36 [Jonathan]: RESOLUTION: lc116 closed with proposal above.
13:53:48 [Jonathan]: Topic: Future meetings.
13:54:46 [Jonathan]: Bob: Call on the 13th is the last opportunity to touch the document. Our fundamental reason for the call is to pass the document off. The meeting will last as long as it takes.
13:56:35 [Jonathan]: Jonathan: suggests we require any comments to be accompanied with a complete and detailed proposal.
13:57:10 [pauld]: +1 to Jonathan
13:57:13 [Jonathan]: RESOLUTION: Comments must be accompanied with a detailed proposal.
13:57:50 [mnot]: mnot has joined #ws-addr
13:58:42 [Jonathan]: Anish: Once it goes to PR it's out of our hands.
13:59:00 [dhull]: dhull has joined #ws-addr
13:59:14 [Jonathan]: Hugo: It's in my hands, so small changes (e.g. editorial) can be made as a result of AC or other comments.
14:00:00 [Jonathan]: Bob: Would like to hear from the test group after the meeting on tuesday, if there are issues that mean we'll slip the date we'll have to reschedule.
14:00:14 [Jonathan]: ... No reason to hold the 8th call - cancelled.
14:00:37 [Jonathan]: ... FTF in Cambridge, MA for May 4-5(?) by IBM.
14:01:17 [Jonathan]: ... Pencil in the FTF.
14:01:41 [Jonathan]: Jonathan: Thinks we'll need it.
14:01:50 [Jonathan]: Bob: Don't by tickets quite yet though.
14:02:36 [Jonathan]: Bob: This is your 8 week notice of the FTF. Possibility it might be cancelled though.
14:02:42 [anish]: s/by/buy/
14:03:12 [Jonathan]: Ajourned...
14:03:17 [Jonathan]: RRSAgent, draft minutes
14:03:17 [RRSAgent]: I have made the request to generate http://www.w3.org/2006/03/03-ws-addr-minutes.html Jonathan
14:03:49 [Jonathan]: RRSAgent, set log member
14:03:56 [Jonathan]: RRSAgent, draft minutes
14:03:56 [RRSAgent]: I have made the request to generate http://www.w3.org/2006/03/03-ws-addr-minutes.html Jonathan
14:05:59 [TRutt]: TRutt has left #ws-addr
14:06:42 [bob]: rrsagent, make logs public
14:07:06 [bob]: bob has left #ws-addr
14:16:48 [Katy]: Katy has left #ws-addr
14:20:22 [prasad]: prasad has joined #ws-addr
14:20:32 [prasad]: prasad has left #ws-addr
15:14:34 [jeffm]: jeffm has joined #ws-addr
15:28:45 [Zakim]: Zakim has left #ws-addr
17:18:54 [jeffm]: jeffm has joined #ws-addr
18:16:26 [pauld]: pauld has joined #ws-addr
18:39:39 [jeffm]: jeffm has joined #ws-addr
21:16:45 [dhull]: dhull has joined #ws-addr
22:24:04 [jeffm]: jeffm has joined #ws-addr
23:03:13 [pauld]: pauld has joined #ws-addr