See also: IRC log
RESOLUTION: minutes of 2006-11-27 accepted
bob: a couple of new issues
... Jonathan noted capitalization problems
... David Illsley's comment on namespaces
DavidI: not sure if my namespace comment needs a new issue
RESOLUTION: close new issue on capitalization with Jonathan's proposal
bob: Paul Knight sent his review
to the mailing list a couple of minutes ago
... people should read and review and be prepared to discuss
this on next weeks call
Paul: I'd be happy to discuss at this point . . .
Bob: given the late arrival, let's postpone for next meeting
RESOLUTION: discuss Paul's comments next meeting
<bob> scribe: bob
Gil: I wrote what I understood to
be out agreement based on the lsat call
... specifically we didn't want the absence of the assertion to
be its negation since that would lead to the cr33 trap
... a number of points made on the list have called into
question some of what I thought we had alredy decided
Anish: I thought that the agreement ws to make the assertions both policy and wsdl markers
Gil: We had decided against that
in the prior concall.
... wsdl would be a coarse grain marker, but policy would fine
tune them
Anish: I was explicitly pushing that the new assertions be usable both in wsdl and policy
Gil: Does not make sense to
discuss anon / nonanon unless addressing is already inficated
as supported
... WS-Policy is pretty mechanical. it would need domain
specific smarts
MarcG: my recollection matches what Gil said
MarcG: I don't dispute the notion
of using matching assertions
... The new proposal nests the Anon/NonAnon under
UsingAddressing
... I'm having a hard time with how we would use
UsingAddressing both as a WSDL marker and a policy assertion if
you can nest Anon/NonAnon underneath
... I thought we had agreed to leave UsingAddressing alone
Bob: so your point is that you don't think the WSDL marker and the policy assertion can have the same QName?
MarcG: It's okay as long as
UsingAddressing is a simple policy assertion
... but when you start nesting other policy assertions beneath
it, I can't see it
DavidI: I haven't thought that through
Glen: It shouldn't be a problem
Anish: There are two issues: do
we want to provide the same capabilities in both WSDL
extensions and Policy
... and do we want to nest assertions
... my understanding is that we were going to provide all the
capabilities as both WSDL extensions and in WS-Policy
... Gil, I don't see the use case
Gil: server advertises "NonAnonymousResponses" client looks for "UsingAddressing" . . they don't intersect
Katy: Anish, two sub-issues of
your first issue
... providing UsingAddressing functionality in WSDL
... and providing "AnonymousResponses" functionality in
WSDL
... the group determined that nobody needed "Anon"
functionality in WSDL
Anish: the idea was that existing impls that don't understand the new WS-Policy assertions need "anon" in WSDL
Katy: concerned because we asked if anyone needed anon in WSDL and everyone said they didn't
Anish: we certainly need an "anon" marker in WSDL
Katy: as long as someone needs it
and someone will implement it, we should include it
... but it makes the spec a lot more complicated
Anish: You think UsingAddressing is complicated?
Katy: No, its not but the "anon" and "nonAnon" markers make things a lot more complicated
Anish: I think it doesn't.
DavidI: There are two different
ways of looking at these separate assertions.
... if we have "AnonSupported" as implying "UsingAddressing",
but this breaks the intersection rules
<anish> btw, i don't care as much about whether it is a nested assertion or not, i care more about allowing it to be used in WSDL
DavidI: if we have separate
assertions so "AnonSupported" doesn't imply "UsingAddressin"
you end up with combinations that are invalid
... these invalid alternatives require domain-specific
knowledge to detect and exclude
Phillpe: Katy commented that if one person needs something we have to do it. I don't agree.
Bob: Who needs "AnonResponses" in WSDL? Just Anish or anyone else ?
<silence>
Bob: Anish can you make the case that "AnonResponse" is generally useful as a WSDL extension?
Anish: I thought I did.
... It will take a while for people to get on the WS-Policy
band-wagon
... Its simpler to add support for a WSDL extension
... That it is to make everyone to go to WS-Policy to learn
abou Anon/NonAnon
Phillpe: Can we do a quick straw-poll?
Bob: <asks for anynone else who thinks AnonResponses need to be a WSDL extension>
<silence>
Bob: <asks counter-question>
<GlenD> ah, blessed apathy :)
RESULTS: 1 need, 5 don't need (no), 1 maybe
<Zakim> plh, you wanted to try to answer the charter question
<plh> "use of Web Services Addressing components in WSDL 1.1 and WSDL 2.0 message exchange patterns and providing the mechanisms for defining Web Services Addressing property values in WSDL 1.1 and WSDL 2.0 service descriptions"
Philippe: DavidH's question is a good one. Depending upon how you read the charter it could be construed that we need to do it in both places.
Anish: The charter talks about WSDL and not WS-Policy. It seems odd to discuss things that have nothing to do with WSDL in the "WSDL Binding Document"
Bob: We have an open issue to discuss the title of the document.
Anish: Our charter doesn't talk
about WS-Policy at all.
... Some people talked about the complexity. Whichever way we
go (nested or not) making the assertions dual-purpose won't
complicate anything.
... I'm willing to put together a proposal to show people how
to use any assertions in both WSDL and WS-Policy
Bob: I was beginning to hope that
we were making progress. I don't want to derail that progress.
I would like to proceed along the lines
... of doing solely policy assertions then revisit the WSDL
extension issue once we get those hammered out.
... Would that be acceptable?
Katy: I'm against the idea of
trying to express "AnonResponses" and "NonAnonresponses" in
WSDL
... If we do it in both places we have the problem of what to
do when the WSDL and Policy disagree
... sticking to just UsingAddressing minimizes the potential
for disagreements
Anish: Is anyone suggesting getting rid of dual-use for UsingAddressing?
Bob & Katy: No
Anish: The problems of WSDL and
Policy disagreeing are already there for UsingAddressing (cites
example)
... Those conflicts need to be resolved in any case so its no
big deal to apply those solutions to AnonymousResponses and
NonAnonymousResponses
Katy: Yeah same pattern, but more
work in each case.
... Fine, if we need both. But I don't think we need
both.
... A lot of extra processing for something that nobody seems
to need very much.
Bob: Our straw poll (if turned
into a formal vote) shows abstain ruling, followed by
'no'
... We could settle this and move forward by a formal
vote.
... On the other hand, we could just defer this discussion
until we figure out how to express what we want using
WS-Policy
... I disagree that the shortest path is to try and address the
WSDL extension issue now.
Katy: OK
Bob: I note that Chris Ferris has thrown a log on the fire with regards to wsdl:required="true"
<Zakim> gpilz, you wanted to discuss Chris' point
DavidO: some people are objecting
to the description of UsingAddressing based on what is need by
the WS-Policy intersection rules
... Some people say we can't have WS-Addr specific policy
handling. I'm not sure if I agree with that.
... WS-Policy is in last call and WS-Addr seems to have a
fairly simple use of WS-Policy. If we need WS-Policy to do
something different we should tell them now.
... Its interesting that one of the first WG's to use WS-Policy
is having such problems.
MarcG: If there are issues found
with WS-Policy we should let them know.
... I think the problems with the intersection algorithm are
overblown. We should just focus on the assertions that we
need.
... WS-SX has a large set of complex assertions and they don't
seem to be having problems.
Tom: With nested assertions we don't have problems with the intersection algorithm. I agree with ChrisF . . .
Bob: Want to get back to prior call. Someone made a statement that nesting policy assertions is just too complicated. Has that changed?
Tom: We were also talking about nesting parameters which is pretty complicated.
MarcG: I was on the previous
calls. I agree that nesting policy assertions is not that
hard.
... Though I question using "UsingAddressing" as the top-level
container.
Bob: Are people ok with using UsingAddressing as a container and putting AnonResponses and NonAnonResponses as child policies?
Tony: The reason that we split UsingAddressing (the WSDL marker) and AddressingRequired (the policy assertion) was because of this split in semantics
Anish: use framework attribute to define required or optional
TonyR: That won't work because there would be different meanings in different environments
Anish: It is a question of what is the default, the defaults may be different, but the semantics are the same
<dorchard> +1 to TonyR's points.
TonyR: If the defaults are different then they have different meanings
DavidI: When I think about this
stuff, I try to think about it in WS-Policy-normal form (no
"optional")
... If we don't have text saying that the normal form means
something different, it doesn't.
Anish: Are you saying that "wsp:optional=true" means that the non-missing case means that addressing is required?
DavidI: Yes.
Bob: Do we have specific changes to Gil's proposal that we would like to make?
Marc: What about David's proposal on Friday?
Bob: Those are commments against Gil's
MarcG: But it changed nesting?
Bob: True
Gil: But I think Bob wants to see a proposal with David's changes to Gil's proposal.
Bob: Right
... Do folks agree that this is the direction we want to go
in?
Tony: I remain concerned with one
thing about the nesting.
... If the outer container can't have "wsp:optional=true" how
do you get the inner assertions to support the required ???
Paco: The point is that "optional" applies to the whole thing
Tony: How can you express that you want an inner assertion but not an outer assertion.
Gil: How/why would I say "I support non-anonymous responses" without saying "I support WS-Addr"?
Bob: Do we agree on the direction?
MarcG: I want to know if we are going to make UsingAddressing act as a container.
DavidI: Let's rename the UsingAddressing policy assertiong to AddressingRequired
MarcG: I would like that.
Anish: Would that be a replacement for UsingAdressing or in addition to?
DavidI: That would be a point for further disucssion.
Bob: I think the point is to distinguish the policy assertion from the WSDL marker.
Anish: So "UsingAddressing" is a WSDL marker and "AddressingRequired" is a policy assertion?
Bob: Yes
MarcG: I think we whould leave "UsingAddressing" alone.
Bob: Leave "UsingAddressing" alone as a WSDL marker.
MarcG: I thought we had agreed to leave UsingAddressing completely alone.
Bob: I thought we were.
MarcG: No, right now you can use UsingAddressing as a policy assertion.
Anish: How can we have both a
UsingAddressing policy assertion and a AddressingRequired
policy assertion?
... They compete and one is a superset of the other (provides
examples)
MarcG: I'd like to see how this
develops. But when you start doing nested assertions you have
to express that assertion (it can't be defaulted).
... That is, if UsingAddressing has child assertions, you have
to express the values of those assertions, you can't leave it
empty.
... Whereas, today, you could have a policy with
UsingAddressing and no child elements.
... There are implemenations that currently rely on the use of
UsingAddressing as a policy assertion.
Tony: I'm reluctant to be bound
to someone's early implementation of a draft spec. They knew
the risks when they did this.
... We don't have to be bound by their decisions.
Bob: Let's figure out what we need to do then figure out how to minimize impact on existing implementations.
MarcG: I agree with Bob. We can't radically change the marker and keep the same namespace. There are implemations out there the use the current namespace.
<plh> "This namespace URI will be updated only if changes are made to
<plh> the document are significant and impact the implementation of the
<plh> specifications.This namespace URI will be updated only if changes are made to
<plh> the document are significant and impact the implementation of the
<plh> specifications."
<plh> http://www.w3.org/2006/05/addressing/wsdl/
Tony: I'm sorry, but we were still in draft stage.
(someone): We promised that we would change the namespace if we changed the semantics?
Bob: DavidI agree to take an AI to update the current proposal to include nested assertions?
DavidI: Yes.
<scribe> ACTION: ITEM to David Illsley to update Gil's proposal to nest AnonResponse/NonAnonResponses [recorded in http://www.w3.org/2006/12/04-ws-addr-minutes.html#action01]
Tony: What about "WSDL Binding and Related Matters"?
Bob: "WSDL Binding, Anti-Poverty, and Peace Document"
Anish: Have we ruled out a separate document?
Bob: Phillipe do you have a position on that?
Phillipe: No
Bob: If there are conflicts between WSDL and POlicy it would be handy to have them together.
Anish: If they are not dual-use there is no conflict.
Tony: One could say one thing and one could say another.
Tony & Anish: (back and forth on possible conflicts between WSDL markers and Policy assertions)
Bob: We are well overdue on our
mandatory heartbeat requirement. We need to publish a new
version soon. Any addition of WS-Policy stuff needs
... a corresponding change to the title.
<anish> Q that i was going to ask: for those supporting no support in WSDL for anon, why would we have a dual use UsingAddressing for WSDL. I.e. won't the same reasoning apply to make UsingAddressing single use (ws-p only)?
Bob: We can decide to split the doc once we have figured out the content
Gil: New name should best be figured out on the mailing list
Bob: True
Anish: If everything is dual-use then it should all be in the same doc
<dorchard> Description Document
Anish: Separate use would seem to require separate documents.
<dorchard> Metadata Document
Bob: WS-Addressing Metadata
Document
... I'd like to get to a heartbeat document very shortly.
<dorchard> I take full credit for the brilliant suggestion.
Bob: I'm hopeful we'll have a section on WS-Policy assertions to add on next weeks call.
Bob: If people in this group has
a set of comments it might be helpful to combine those comments
as a group response.
... There are only three calls between now and the end of the
review period for WS-Policy
... Would like to make sure we can do what we need using
WS-Policy and I would like to do that in parallel with the
review period for WS-Polcy.
MarcG: The WS-Policy primer has examples that show the use of the UsingAddressing assertion. Good place to start . . .
Tony: You are suggesting that if we change UsingAddressing, they might not be happy?
MarcG: No.
Anish: Is the Primer in last call?
(all): No
Bob: But we should look at the Primer as a good place to start.
MarcG: I put the link in IRC
Bob: For next weeks call we have the review of Paul Kight's AI, a review of the propsal from David Illsley.
ADJORNED