See also: IRC log
previous minutes 2007-05-14 are approved.
Bob: interop test in Ottawa, co-located with WSP. MS and IBM did the testing.
David: we got interop across the board.
ms<->ms, ms<->ibm, ibm<->ibm.
... it's all green.
Bob: section 2 hasn't been tested however...
David: some of it were tested last year during
interop with Sun.
... we intended to test it with them, but didn't have time. I wonder if Sun
would be willing to achieve the testing.
Bob: section 2 is related to WSDL on the EPR.
... section 2.1 is described as required in the conformance section of the
addressing specification.
... but the conformance section indicates only that any child element must
conform structurally with the specification. is it intended that way?
David: my reading of section 2.1 and conformance simply requires that an EPR processesor to read the metadata section. I don't believe that the conformance requirement imposes to dereference the WSDL.
Bob: so any processor that doesn't reference
is conformant.
... we now have a choice to make: CR call for implementation with marking
some section at risk, or go directly to PR.
... looking at the test matrix, going to PR today, we would need to trim out
those sections that do not meet the exit criteria of the charter (2 impls),
the only features are those in section 2.1 and 2.2.
... so, what should we do?
Ram: section 2.1 and 2.2 are optional imho. any objections to that?
Bob: are you looking for rephrasing in conformance section?
Ram: yes, we should make it clear if section 2 is optional.
Bob: if it's not clear to Ram, we should clarify the spec.
Ram: we could remove the first statement of section 6.
<Ram> 6. Conformance
<Ram> An endpoint reference whose wsa:Metadata element has among its children the elements defined in 2.1 Referencing WSDL Metadata from an EPR conforms to this specification if it obeys the structural constraints defined in that section.
Katy: if the point of that section isn't there to indicate that the elements should be syntactically correct?
Anish: why would we not want the implementations to behave the way we specified?
Ram: is that a required feature or not?
Anish: there are certain things that you have to do to conform to the spec, but if you do that optional normative stuff, you are required to do what it says.
David: my take is that nothing in the
specification defines solution to the potential problem of embedding
metadata. Those could be out of date, etc.
... we're not going to solve that issue.
... I don't believe that the spec should require any processing of the
metadata.
... those metadata can be expensive processing for example. that's why you
don't want to require processing.
... regarding the conformance section, it simply says that the multiplicity
is right.
Bob: choices are to produce 2 interoperable impls for each of those features, or to drop one or both.
Anish: even section 3 is optional, but it still part of the specification.
plh: [...]
Philippe: do we expect an implementation to reject an EPR with 2 serviceName?
Anish: yes, we do.
Tom: one minimal test would be to make sure
that one can accept an EPR that contains those metadata.
... that might be enough of a test.
Katy: two issues here. are those sections optional? the sentence is really about when the EPR has among its children elements from section 2.1.
<anish> agree with katy
Katy: it doesn't say anything about the optionality of 2.1
Ram: don't disagree with Katy's statement, but when the tooling sees the data in there, can it barf? Does an implementation have to parse and understand the semantics of section 2.1?
<TRutt__> understanding semantics is untestable
Ram: if the tooling doesn't have to do anything with it, we should make it clear in the spec
Bob: how would you modify that sentence?
<David_Illsley> how about at the end of section 2: NOTE: This specification does not override Core section 2.1, in particular, because the specification does not specify how to deal with the problems mentions, EPR users are free to decide whether or not to use this embedded metadata.
Ram: need to think about it
Anish: if the tooling treats it as any, then it's not checking the syntax that we define and shouldn't be claiming conformance to the spec.
Ram: then the tooling is required to
understand the syntactic part.
... it cannot be treated as any, there are some expected behaviors.
Anish: there are some syntactic constraints. the sentence is quite clear as it is.
Ram: so the implementation has to do something...
Bob: yes and schema validation would be enough
Ram: from our point of view, we don't think
that section 2 is the right approach from our product point of view.
... we don't expect to implement it.
plh: you have to do schema validation, that's what the spec says.
Bob: on section 2.1 and 2.2, what are our chances to get implementations?
David: given the late requirement, I'm willing to implement both.
Bob: so IBM is willing to implement section
2.1 and 2.2. Do we have another?
... MSFT does not intent to implement 2.1 and 2.2. Correct?
Ram: I believe we support 2.2 already but we are not planning to carry that forward.
Bob: ok, anyone else?
Tom: speaking of MSFT, we are just saying that they should do the conformance. correct?
Bob: specifically, the rule calls for interop
implementations. they are expectations that those implementations turn into
products. Although, it would be odd to participate in the CR phase and not
conforming to it in the product.
... unless we are able to come up with 2 implementations, we cannot progress
these features.
... Sun has done some earlier interop.
Rama: we're not currently implementing the metadata spec. we're trying to understand the use case. I do think that section 2.1 is important. I do need to talk more internally.
Bob: so, do we go through the CR path or the
PR path?
... for CR, we need interop. We could wait for it.
... how long does Sun need?
Rama: I don't have an answer right now.
Bob: how much time for the internal discussion?
Rama: within a day or two.
Tom: WS-Policy is now expecting to have a PR something in July or August. For a practical point of view, late July/early August would be acceptable for me.
5 to 6 weeks.
for PR
Bob: there is no constraints for CR phase.
... we could have a 5 minutes CR phase.
... we do have another item on our way, the IP exclusion running until
mid-July.
... the only way to go to PR earlier than July 15 is for all companies to
agree to clause the exclusion interval early.
... so it may very well that we can't go to PR earlier than mid-July.
Katy: doing interop on 2.1 and forgetting 2.2
would be ok for us.
... if we go to CR and mark those 2 sections at risk, then proceed quickly
through CR (one to two weeks0.
Bob: I would propose to end the CR period
around July 15 and if we don't get impls by then, those sections will be
gone.
... the conclusion of the CR interval would be end of June. (3 weeks CR)
Katy: this would be acceptable to us.
Ram: given where we are today, I'm wondering our chances to meet those deadlines?
Bob: depends on how quickly we can resolve this issue.
Ram: an other issue with section 2.1: it's
using the wsdli namespace, which only occurs on wsdl 2.0.
... could wsdl 1.1 implementations compose with this spec?
David: yes, it could simply ignore it.
Anish: I queued to answer the question: can you use wsdli with wsdl 1.1? the answer is yes.
Ram: wsdli namespace is not defined in wsdl 1.1
Anish: you don't need to understand wsdl 2.0 to understand wsdli.
Ram: we do agree that a addressing implementation has to understand the namespace
Anish: yes, you have to understand the qname.
Ram: I'm trying to point out a problem here. should a wsdl 1.1 implementation support this new namespace?
David: the wsdli is trivial to implement.
... I don't think it has to implement.
<Ram> Introduction: WS-Addressing is designed to be able to work with WS-Policy 1.5 [WS Policy 1.5], WSDL 2.0 [WSDL 2.0] and also (for backwards compatibility) with WSDL 1.1 [WSDL 1.1] described services.
Anish: agreed. Ram, are you arguing against the spec, or are we talking about interop implementations?
Ram: it's not clear to me that section 2.1 has it stands really composes.
Anish: if you have existing wsdl 1.1 artifacts, you may recognize other qnames. that separate from being able to reuse existing artifacts.
Ram: for us, it doesn't seem to be the right approach.
Bob: do you have a concrete issue to raise?
Ram: I do not want to push forward with any issue at this point.
Bob: proposed resolution: we try to close the remaining issues that we have, then we start a CR interval and try to conclude at the end of June, marking section 2.1 and 2.2 at risk.
[no objection]
Resolution: short CR, with 2.1 and 2.2 marked at risk.
Katy: trying to find the dependency with the
policies specifications.
... they are all moving towards being policy framework independent.
... I wonder if it's good idea to follow the example of RM
... we should modify the document to make the namespace generic.
Anish: this would be a bad idea. RM, etc are
going to charter clarifications to only use Policy 1.5.
... the reason why it was done like that in OASIS is that the policy
specification was not ready.
<TRutt__> +1 to anish
Anish: my company would like to see the specification based on W3C technologies.
Katy: I didn't realize that the intention was
to move towards to 1.5
... are all the specs going to move to 1.5
Bob: RX and TX do intent to do this.
Anish: SX as well
Katy: are there going to be usable with policy 1.2?
Bob: I don't hear much sympathy for that.
Tom: one could claim conformance with the older spec if they want to.
Resolution: issue is dropped, withdrawn by submitter
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2007May/0003.html
Bob: in section 4.4, we talk about best
practices regarding the action property.
... but [[Unfortunately, the default action pattern for a WSDL 2.0 fault
message does
NOT "fulfill that best practice.]]
David: always assumed that the best practice is about input messages, and not output messages.
http://www.w3.org/2002/ws/addr/wd-issues/Overview.html#i017
For each Interface Operation component in the {interface operations} property of an Interface component, the {name} property MUST be unique.
<anish> Despite having a {name} property, Interface Operation components cannot be identified solely by their QName. Indeed, two Interface components whose {name} property value has the same namespace name, but different local names, can contain Interface Operation components with the same {name} property value. Thus, the {name} property of Interface Operation components is not sufficient to form the unique identity of an Interface Operation component. A method f
Gil: example 4.4 shows that the operation name doesn't appear in the wsa:Action.
Tom: a fault is returned in response to a
message, you should already be correlating the two.
... I think this is a misunderstanding. the action is for message in, not
for message out.
David: I don't think that the potential benefit of uniquely identifying faults is worth breaking compatibility with existing implementations.
Bob: any editorial clarification?
<anish> it seems that either we should remove the reference to wsdl best practice or add operation name to the fault action algo
Anish: either we remove the best practices comment, or we change the fault algorithm.
Bob: changing the algorithm would be a breaking change.
David: I'm not sure it is really a best practice we can refer to.
Anish: this was at the time why we needed
action.
... we pointed to the wsdl best practice because we needed it.
Bob: would it be enough to remove the comment about best practice?
Gil: I don't think that solves the problem
... two choices: a. you have a point but we don't think the point is serious
enough to disrupt the spec, or we try to address it.
David: option a sounds reasonable. it isn't serious enough to fix the specification.
<dhull> +1
Resolution: issue is closed with no action
<scribe> ACTION: Gil to answer the comment on action property to the commenter [recorded in http://www.w3.org/2007/06/04-ws-addr-minutes.html#action01]
Bob: any more issues?
Ram: Is there is one issue from David Hull?
David_Hull: which one is that?
... I thought we nailed the issue of composability before
Bob: I received an ack to cr33. so it's
closed!
... move to CR for the end of June, marking 2.1 and 2.2 at risk?
... if we don't reach the CR criteria at the end of June (2 impls), 2.1 and
2.2 would be removed.
<gpilz> easier just to list it as "Section 2"
<gpilz> since "Section 2" is made up entirely of 2.1 and 2.2
Resolution: move to CR as soon as possible target completion for the end of June, marking 2.1 and 2.2 at risk
Ram: how does this decision intersect with the exclusion period?
Bob: on the 15 of July, we would request to
move to PR.
... this means end of august for the REC.
... I'm assuming that during the CR, nothing major will happen. I'll ask the
group to vote to accept new issues.
Bob: I was thinking to have it on July 2.
David: this doesn't leave any meeting for the
group to approve the testing
... I'm ok with it. otherwise, we should have an early meeting.
Bob: So, the interval will be June 29.
Next meeting will be June 18, to discuss testing
and then July 2 to act on the result of the CR period.
Prepare final text for distribution to the director for review, then try to have the meeting with the Director on July 16.
[adjourned]
<bob> thanks philippe for scribing