See also: IRC log
Anish stated that xmlp requested requirements from this WG
Agree to put on agenda after wsdl coordination
Also add discussion of f2f
Dial in should be available
Hugo will send in details on Dial in for F2F
<bob> +1 for dinner
<swinkler> Nola is fine.
<GlenD> Nola's great
<uyalcina> tamarind is better
<swinkler> Tamarine is better, that's true.
<GlenD> The place with the sake bombs is fun too :)
Take Dinner arrangment to list
<swinkler> that's =myake's
No objection to posting to web site
Resolution: minutes sep 12 approved
Topic Agenda item 5 coordination
Mark N: Last week we came to conclusion about some of the comments members put together on WSDL document review.
Sent Tony comments on core
Concluded that there was not much to add to Marc G comments.
<Marsh> The comment Dave filed: http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Sep/0014.html
Dhull: Wording seemed to suggest annotations for IRIs, since it did not mention something else. I wanted the text to be clarified.
<dhull> http://www.w3.org/2002/ws/desc/5/lc-issues/issues.html#LC336
Dhull: I already submitted the comment as a last call issue
Mark N; I thought we were going to review it further, lets see if the WG agrees
Nobody objected to LC336 as comment to wsdl group
<uyalcina> I can live with it
Mark N : move on to Katy comments
Katy: First comment regarded a
comma.
... on second comment about 5.10.3 -
Jonathan: this "element" should be this "global element declaration".
<uyalcina> I don't like the second sentence
Katy comments at: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0023.html
Mark N: we do not heed to produce fix, we just need to identify problem
Katy: third comment para under 5.10.3 The following sentence switches between a SOAP Header Block representing 1
header and representing multiple headers?
"A SOAP Header Block component describes an abstract piece of header data
(message headers) that is associated with the exchange of messages between
the communicating parties. The presence of a SOAP Header Block component
in a WSDL description indicates that the service supports headers and MAY
require a Web service consumer/client that interacts with the service to
use the described header. Zero or more such headers may be used."
Jonathan: this comment should be sent in.
Katy: comment 4 o Comment: How does wsoap:header indicate required = true/false?
Johathan: how does client know by reading wsdl whether it must send the header?
Katy comment 5 on section 5.10 Comment : Use of wsoap:header Element Information Items
WSDL Adjuncts Section 5.10
What is the intent of the (non-'document') element information items in the wsoap:header?
Mark N: agreed to drop this comment
Katy comment 6 o WS-Addressing WSDL spec ?
wsaw: UsingAddressing appears to be simply a shorthand for wsoap:headers.
Would it be worth us adding the semantic equivalent to
wsaw: UsingAddressing in terms of WSDL 2.0 SOAP header blocks as part of the WS-A WSDL specification?
Mark N: Katy should keep this for discussion at the Face to Face meeting.
<anish> a related question: what happens if both wsaw:Action and wsoap:header (for wsa:Action) is present and is different?
Katy: I will think about this further, and maybe will add an issue later if required, perhaps asking for a clarificaiton
Jonathan: it depends on the MEP which headers are required or optional
Mark N: we do not need to resolve this now.
Mark N: for wswd doc review we have the tony comments, all but the last two of Katy, and DHulls single comment
Mark N: any objection to sending in comments as discussed.
No objection
<scribe> ACTION: katy to send all but her last two comments [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action01]
<scribe> ACTION: Tony to send his comments [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action02]
Jonathan: Marc G had an editorial comment,
Marc N: those comments are not relevant to addressing
<mnot> http://www.w3.org/mid/A5F46F7A688C084782E8C52B76368613014CC5F2@sdebe101.NOE.Nokia.com
Jonathan: I will have him send these in on his own behalf
Mark N: xmlp is asking us for our requirements, we discovered in the past that we could not articulate requriements unto the asynch task force was completed. After discussion next week we may be able to get back to them.
Mark N: is it reasonable to wait until after next week f2f before sending this response.
GlenD: that is what we discussed on the last asynch TF call. We are currently figuring out how to spec this.
Mark N: we need to have the WG review this document first. We have pressure to agree to something by end of next week. I will devote much of the agenda next week to this issue.
<anish> +1 to devoting significant time at the f2f for this
<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0020.html
Anish: reviewed his email at
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0020.html
... after I sent this email, I am less convinced that we need
to say anything.. If we understand what port and endpoing mean,
wrt address of port or endpoint, then I do not think we need to
say anything, We cannot change wsdl 1.1. Including epr within
port is no different than soap:address within a port.
Mark N: does everone agree with anish sentement.
Mark N: hopefully we can close I056 next week.
Mark N: Last time we agreed to wait for resolution of i056 before doing this.
Agreed to discuss at meeting next week.
GlenD: The Asynch task force agreed on a few things: 1) wire level representation of use cases (one way over one way protocol, and over two way protocol ; and 2) in/out over one way and two way protocol.
Glen D: having agreement on wire level, we discussed how to do this in soap 1.2 framework for bindigns as well as wsdl 1.1 and 2.0. This is where is gets tricky. Do we build on top of those specs, or issue errata.
GlenD: agreed that when using
addressing and want an asynch reply for wsdl in/out, you should
be allowed to specify in wsdl the allowed bindings for the
return, but the detailed changes to the specs (soap in
particular) is still under discussion
... We need to go thru some questions to evaluate the various
proposals.
<uyalcina> +1 to anish
Anish: we need to make paths along the decision tree that GlenD sent out.
Mark N: everone should look at the decisions and GlenD's summary of the discussions. Ask questions on the email before the meeting.
Mark N: we should wait for the outcome of Paco action item on this issue.
<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Aug/0088
Jonathan: my email http://lists.w3.org/Archives/Public/public-ws-addressing/2005Aug/0088 shows a reasonable approach to take.
Jonathan problem action overlaps with problem header
Jonathan: instead of having a
problemAction, I propose we keep problemHeader, and
problemHeaderQname, and use this to indicate problem in action
header.
... you could also use problemSoapAction
dhull: in Boston we moved in a general dirction to trim codes, and as long as this is in the same direction I am comfortable.
Mark N: would this cause us to go back from CR and go to draft. Since we flagged this, we should not have to go back from CR
Mark N: would it cause our namespace to change?
Marc H: It would have to.
Jonathan: the scema should change.
Marc H: then we have to change the namspace.
Mark N: was that element requried before?
Marc H: is changing namespace a big issue at this CR phase?
Jonathan: if we agreed on this fix soon enough, we could have it in the spec going forwared for interop. We could process this as errata soon.
JeffM: do we need to change the namespace.
Mark N: we agreed to a namspace evolution policy last week, and after CR if at all posible we would try not to change namespace.
Anish: what is the problem with changing namespace?
Umit: if there are no implementations, why not just change it.
Anish: CR documents are not final. Things may change.
Dhull: people are referring to the CR docs.
JeffM: any reference to a spec under development is subject to changes occuring.
Jonathan: if there is no reason to change the namespace we should not. The question is whether this is a breaking change.
Marc H: removing element and adding new one is a breaking change.
Jonathan: from our point of view, we could accomodate this change at this time. However later in the CR process we would not be so flexible.
Hugo: an open source developer might implement the CR spec, and if so that would not interoperate with the final spec.
Anish: is this change important enough for a breaking change. If yes, we should change the namespace, otherwise we should look for a backward compatible change.
<pauld> wonders what the impact on publication if we do change the namespace, do we have to go back to LC?
Mark N: if this was the only breaking change, how important would it be it to do this?
Hugo: we already made a change from CR1.
Marc H: that just changed the prose, not the schema itself.
Jonathan: I agee with Marc that dropping somenting from schema requres a new namespace.. I would prefer not to include this change if the namespace had to change.
Katy: would id affect interop if the namespace does not change, but the schema does?
Marc H: taking something out and putiting something back in without changing namespace is dangerous, because it will cause problems in an implementation stating what schema it has implemented.
Umit: I agree with Marc H.
<Zakim> anish, you wanted to ask as to what we put on the backburner -- this issue resolution or whether we change the NS or not?
Jonathan: The decision on this issue depends on how many other changes we get. If there are other big changes, we could include this resolution. If there are no other big changes, we might decide to not include this resolution.
Anish: should we put this issue on the back burner.
Mark N: yes.
<Zakim> hugo, you wanted to talk about wsa:InvalidAddress
Jonathan: if there are several changes required, we would have to bite the bullet, and include them, thus changing the namespace.
Hugo: I found some other related
issue with invalidAddress. Should I open a new issue about
this? I put it on the email list already.
... there is a problem with "probliemIRI" datatype. I will take
with people next week to determine if it is necessary to raise
a new comment.
Mark N: can we defer the resolution of this issue?
No objection to defer resolution.
<mnot> http://www.w3.org/2002/ws/addr/cr-issues/#cr3
Mark N: this seems out scope for us, and is for those using addressing
Gil: As a courtesy we should say in the spec that when signing addressing headers we should pick one ID.
Jonathan: I do not see why we should say anything. The security layer should make that decision.
Anish: Ws addressing is no different than any other spec defining soap headers. I am not sure we have to say anything in our spec.
Jonathan: I propose we decline to do any change to the spec.
<MSEder> let jon do it
<scribe> ACTION: Jonathan to write rationale for declining and send it out for review by WG [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action03]
Mark N: any objectons to close with no change.
<bob> more that the issue is out of scope
Resolution: close CR3 with no action
<scribe> ACTION: jonathan to informally respond to John Kemp with rationale for closing cr3 without change. [recorded in http://www.w3.org/2005/09/19-ws-addr-minutes.html#action04]