See also: IRC log
No comments
No objections
RESOLUTION: Minutes March 28 approved without objection
<anish> Scribe: TomRutt
Paul Downey will own issue 42
correction (Issue 41 not 42)
ACTION: Paul D will work on a test cases document as a basis for discussion
<gdaniels> +1
<TonyR> +1
<stevewinkler> +1
<prasad> Make sense to me
<RebeccaB> +1
No objection to moving forward on test cases document based on Paul D action item
<scribe> scribe:tomRutt
Hugo: need to make sure the correct IPR statements are in document
<scribe> ACTION: Hugo will review IPR details on test case documents [recorded in http://www.w3.org/2005/04/04-ws-addr-minutes.html#action01]
<scribe> ACTION: Paul D will create test cases document for discussion [recorded in http://www.w3.org/2005/04/04-ws-addr-minutes.html#action02]
<mnot> http://www.w3.org/mid/2447cc0a543d55afb4ee89bea1ea0982@bea.com
Mark: is there anything else which is a requiremt for the wsdl charter?
DOrchard: are new MEPs or bindings within the scope?
<uyalcina> +1
MarkN: If we decide that we need to make asynch happen, we will not say no to it. If so we have to figure out how to go about doing that.
DOrchard: anything to help wsdl one way with ws addressing should be in scope
<dorchard> or is there good standing cloaked as well?
<anish> +1 to we should do so
dorchard: we should deliver staight up one way and asynch request response
Gudge: are we really talking about how we indicate in wsdl how a mep is asynch, and whether there are one or two flavors of asynch
uyalcina: we have to deal with one way messaging approprately to be able to get there
dorchard: the xml protocol wg did
not produce a soap binding for asynchrony
... however the addressing wg could do the wsdl extensions
necessary.
... I included documents which may be needed by reference in
our wsdl document.
MarkN: our question is what do we
need to move forward regardless of who does it.
... I have not heard anyone wanting to take asynch out of
scope
... we need another issue on our issues list on how to work
with asynch in meps where it is not supported, who is willing
to propose new issue
uyalcina: two separate issues, oneway wsdl binding and asynch
Anish: the oneway is a necessary building block toward full asynch
MarkN: are we talking about oneway soap binding or oneway wsdl binding
dorchard: range of possibiltieis: One way only, another option in optional out soap http binding.
MarkN: who can volunteer to provide issue.
gdaniels: i will take the action to provide the new issue.
<mnot> ACTION: GlenD to propose an issue that captures the async issue [recorded in http://www.w3.org/2005/04/04-ws-addr-minutes.html#action03]
<dorchard> 3 possible new bindings: one-way (2/4/5xx have no body), in-optional-out (200 might also have body), in-optional-fault (200 can't have body but 4/5xx may have body)
hugo: if we have new soap binding available, we have to refer to thes in our wsdl binding document.
MarkN: soap binding and soap mep does not have to be part of wsdl doc, but they have to be used and tested. Thus they have to appear somewhere. Either do it here or ask xmlP to do it. Or wait for output of asynch task force
Marsh: I likk the idea of a new issue in the issues list
dhull: I believe there are three of four issue lurking in this area
MarkN: discussions from Asnch
task force should get into this new issue as wll
... we are not sure wsdl2.0 will be done in time. We could have
a separate wsdl 1.1 doc out there, waiting for the wsdl 2.0
additions when ready.
Marsh: I like the idea of
focusing on wsdl 1.1. But I do not understand the difference in
a wsdl 1.1 not vs a full recommendation with the wsdl 2.0
additions.
... we have to consider how we would publish these in
sequence.
anish: I sent an email with a new
issue about separating wsdl 1.1 and 2.0. I do not see it on the
issues list
... people need a stable document for wsdl 1.1 to implement
from, so we need a separate document. I have not thought about
the form of the document.
... is there a problem with having two rec track docs, one for
wsdl 1.1 another for wsdl 2
MarkN: there is concern about
making wsdl 1.1 stuff normative in w3c recs
... you could not implement a rec referring to wsdl 1.1 note
without also implementing the note.
Prasad: is WSDL 2.0 a gating item for ws addressing becoming a recommendation?
MarkN: we have to decide on our
exit criteria, but we have not yet had that discussion.
... anyone think it not good to produce a first document on
wsdl 1.1
Marsh: I think that would be a
bad idea to have a note. If the idea is to have stability, then
a rec is required. My pref is to have a separate rec for each
of these two wsdl bindings.
... a Note does not give the same protections that a full rec
does.
Mark: could publish as a wd with both in, but the wsdl 1.1 would be completed earlier
<uyalcina> +1
uyalcina: I am not sure what the concern is about having two separate documents.
anish: I did not say to go the note route
Paco: ask w3c what the concern is about two separate recs
dorchard: we will need a formal response. However there will be back and forth negotiation involved with w3x.
uyalcina: it is already in our charter. wsdl 1.1 is widely adopted and used.
MarkN: w3c has concerns about protecting their brand. We should have a discusson going on in the background.
hugo: having one rec with both is different than two recs, with one only pointing to wsdl 1.1. I will be having discussions with mark about this.
Marc: at what point in w3c process would be have to stop the document if we kept them together, given unstable references.
hugo: we could go to CR as long as wsdl is in last call. But there may be technical reasons to be more conservative.
Marc: as long as we can get into a rec level, that does not seem too bad to me.
anish: I do not undersand Hugo's concern about two separate documents.
MarkN: I am taking an action to talk to the team, to determine their concerns, then to get back to the group.
anish: it is not clear looking at wsdl what the destination header should be.
<gdaniels> +1 to Anish
Paco: my proposal was not trying
to answer all of issue 21 concerns. Several things the client
must send are not included in the wsdl.
... we could define some conventions in this area. However we
do not have to have complete specification on how markers in
wsdl relate to all addressing headers.
Anish: I was looking at all of issue 21. Depending on how we resolve the destination concern, it may have an impact on the marker in the wsdl.
MarkN: we probable need a separate issue on the relationship of the destination property and the wsdl marking.
<mnot> "In particular, the relationship between message properties and WSDL 1.1 and WSDL 2.0 service descriptions will be provided if applicable."
Anish: I would be happy with that
being another issue
... we also have to bundle the issue on how to represent ref
param in wsdl. You might be having multiple services at the
same endpoiint address, thus the parms may be used to resolve
the service.
<mnot> ACTION: Anish to propose issue about relationship between Destination property and WSDL [recorded in http://www.w3.org/2005/04/04-ws-addr-minutes.html#action04]
gdaniels: if you put ws addressing in the wsdl, you need to be able to receive addressing headers. If you put it in as optional, then it should be ok for the sender to not use addressing headers.
Paco: from the client perspected
wsdl:required=false can mean the client can ingore ws
addressing semantics.
... you are trying to economize two binding semantics in one
binding
dhull: if the marker is not there at all, the client should infer that the server will not take notice of addressing header. If required = true then you have to send wsaddressing headers. If required =false, you can send the headers, but do not have to.
Paco: I intended to define it as
if it is True you have to send the addressing headers.
... It is not clean to overload the binding to have
required=false to mean two things. But we should not spend too
much time on this.
anish: if the client does not understant the ws addressing headers, required=false means they do not have to provide them.
dhull: required = true allows whatever flexibitliy is in the ws addressing spec.
MarkN: Marc talked about putting the marker on a wsdl port.
Paco: I prefer it in the binding, but the port is ok for me.
MarkN: Prasad brought up issue of multiple versions of binding.
Paco: If new version gets new namespace this is taken care of.
dorchard: this is not the only way to do versioning.
gdaniels: when the ws addressing spec changes in a signicant way, the namespace for the marker can change. the wsdl user will see this as a different marker.
Prasad: this is not the most elegant way to do this. It requires the wsdl user to understand two documents.
Marsh: are you asking for a version attribute on the marker?
Prasad: I guess I can live with this.
<mnot> "The components must be defined so as to allow binding to protocols other than SOAP."
MarkN: can Paco come up with a revised proposel
Paco: yes
<gdaniels> incidentally, wrt the SOAP-specific issue, I think a single marker whose semantics change depending on where it is would be a little weird.
<mnot> ACTION: Paco to revise i021 proposal [recorded in http://www.w3.org/2005/04/04-ws-addr-minutes.html#action06]
cancel call on April 18
<gdaniels> I'd prefer an "abstract" marker which could go at the interface level, and a "concrete" SOAP marker (which could either be the module syntax or syntactic sugar for it)
<gdaniels> ...then other bindings could decide how they want to do it
MarkN: do we need to have the marker proposal more complete before working this issue.
Anish: we can talk about what is
required.
... independent of what the marker looks like, is it important
to have a marker to optimize processing at the interface
level.
MarkN: an earlier concern was that a marker plus another action mechanism could allow the two to get out of synch.
Marsh: need to determine conformance requirements for such markers. What would happen if marker is put in but it is not stated as required.
markN: Anish should watch the discussion around 21, and eventually to make a concrete proposal based on the progression of issue 21 resolution.
+1 anish
<mnot> http://www.w3.org/mid/42517FD4.9070206@oracle.com
Anish: what does it mean if wsdl
service and port information is in the EPR. The address
property does not have to be a physical address, and is not
necessarily where you send the messages.
... the usl is for a new proposal, which does not mention words
"logical" or "physical"
Paco: if wsdl metadata is not present, then do you use the address in epr to send the message to.
Anish: our spec does not define
this behaviour. What if the 'address" is a URN rather than a
URL.
... this proposal just discusses what happens when the epr
minter includes this wsdl metadata, and does not express what
happens if the wsdl metadata is not present.
Marsh: does this information include policy information?
Anish: Yes, that is why is used
the word "information?
... if an epr has conflicting information, it should be
considered an invalid EPR.
uyalcina: in many cases the EPR will be more up to date than what is in the wsdl document., But this is not always the case.
Marsh: can you always tell whether metadata is contradictory?
Anish: should we raise a new issue about the general metadata bucket, which can include "policy" metadata, wsdl metadata (including policy information). The issue is regarding concistency of such metadata.
MarkN: is this not the same as an earlier issue (14)?
Anish: is this is already resolved then I will not raise a new issue.
MarkN: people seem to need more time to review the most recent proposal for issue 20.
Anish: please suggest any better wordings on the list.
MarkN: we have one conf call next
monday, then we have the f2f on the following week. We should
try to get into a good position on the progression of the WSDL
binding document.
... It would be good to have any issues documented before the
F2F. We can also discuss any LC issues which have been raised
by the F2F.
<stevewinkler> adios.
adjourned at 5:56