Administrivia

Bob:minutes from last meeting approved without objection

Bob:Paul Knight completed his AI

bob: looks like a new issue on the list from Cindy McNally, could be a duplicate: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Dec/0019.html

<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Dec/0020.html

plh: properties in WSDL 2.0 are inherited by default

PaulKnight: there is a requirement they should be unique

plh: doesn't seem to be an issue, at least for this WG

Bob: operations must be unique within the same interface

Anish: infault and outfault with the same name might be an issue, but not for WSDL 1.1

Tony: you can reuse a fault, but not sure if you can on the same operation

Anish: default pattern does take into account the direction, so not an issue
... direction token may be used to differentiate between input and output

<plh> Each WSDL 2.0 or type system component of the same kind MUST be uniquely identified by its qualified name. † That is, if two distinct components of the same kind ( Interface, Binding, etc.) are in the same target namespace, then their QNames MUST be unique.

<plh> http://www.w3.org/TR/2006/CR-wsdl20-20060327/#InterfaceFaultReference

plh: WSDL 2.0 describes faults at the interface level and then the faults are referenced with an indication of direction

Bob:response is that they are inherited and interface should work therfore no change is required

<scribe> ACTION: PaulKnight to respond to commenter [recorded in http://www.w3.org/2006/12/11-ws-addr-minutes.html#action01]

RESOLUTION: closed new issue cr41 with no action

CR33 (Groundhog Day)

WS-Addressing Policy Assertions

DavidIllsley: outlines his proposal

<bob> DavidI's proposal http://lists.w3.org/Archives/Public/public-ws-addressing/2006Dec/0016.html

Anish: use nested elements for UsingAddressing? How do the two top level elements interact

<GlenD> <AddressingRequired optional="true"> is just... weird.

DavidIllsley: 2006-05 UsingAddressing can't be reused as you need to nest the asserton inside Policy

Anish: two different qnames for UsingAddressing, or is there a single assertion with two elements nested within it?

<GlenD> I do like the two sub-assertions just fine for anonymous, and think optional makes total sense there.

DavidIllsley: single sounds better

plh: did you consider policy assertions with parameters?

DavidIllsley: parameters aren't a part of the intersection alogrithm

<GlenD> Policy assertions with params would look much cleaner, but require domain-specific intersection. Sigh.

plh: why would you like the intersection to fail (cites anonymous responses use-case)

DavidIllsley: there are situations where you might want it to fail and others where you don't care

<dhull> is it WSP's job to protect you from yourself, or should it just tell you what you're up against (or am I missing something)?

Anish: appropriate policy matching was the reason to go towards nested assertions

DavidIllsley: marking with wsp:optional on the nested assertion gives you felxibility, you can't do this with parameters

plh: you need domain specific handling in such cases

DavidIllsley: example 3 demonstrate intersection (will intersect with example 1 where no nesting on top)

Bob: Can we accept David's Proposal?

No objections Heard

RESOLUTION: David Illsley's proposal for addressing policy assertion is accepted

<GlenD> +1 to Anish!

<scribe> ACTION: Editors to incoporate David's Nested Policy Proposal [recorded in http://www.w3.org/2006/12/11-ws-addr-minutes.html#action02]

<GlenD> dual marker/policy assertino would be vastly preferable

<GlenD> imho

plh: what remains in the WSDL binding?

<scribe> Chair: wsaw:UsingAddressing

Anish: do we make David's assertions dual purpose, and do we need wsaw:UsingAddressing any more (it's a WSDL marker and a Policy assertion)

Bob:we've had some discussion on this

<GlenD> wsaw:UsingAddressing could, IMHO, simply be defined for use either as a policy expression or as a WSDL extension....

Gil: against reusing David's policy assertions as WSDL extensions, but nesting and making them semantically equivalent will be a lot of work.

<David_Illsley> GlenD, if only it could

<GlenD> (and then we wouldn't be saying "addressingRequired is optional" either :) )

<TonyR> the problem is that there has to be a different default for Policy and for WSDL

<GlenD> different default?

Anish: it is inconsistant to say Policy is to be used, but then provide an incomplete WSDL extension
... CR draft with a namespace is there, and some folks are using it

Tony: Glen asked what the problem with the different default. UsingAddressing is made required by wsdl:required, make it optional using policy features - using the same qname for the optional and required versions is going to cause confusion

<GlenD> I'm sorry I don't quite get that. By "default" (with no modifiers) it follows the rules of whichever context it's in, right?

<GlenD> Why is that a problem?

<TonyR> Because it is horribly confusing

<GlenD> Anything in a <wsp:Policy> container is required by default

<GlenD> Any WSDL extensino is non-required by default.

<TonyR> it's a different meaning, so it should have a different name

<Katy> I agree with Tony - policy marker with different semantics should have different name to reflect

<GlenD> the extension just defines the SEMANTIC that is then interpreted... that's all

<GlenD> it's the same semantic, isn't it? i.e. when it's on/selected/in-use

discussion of the separate qnames

<TonyR> no - different meaning - the marker alone is "obligatory" in Policy; the marker alone is "optional" in WSDL - that is too confusing

<GlenD> it's not a huge deal and we shouldn't waste too much time on it IMO, but it seems cleaner to me to simply call it "UsingAddressing" and have it done.

<GlenD> I disagree that it means different things.

TRutt: current spec says you can use this in other contexts including WS-Policy

<TonyR> I'm much happier to have "UsingAddressing" in WSDL, and "AddressingRequired" in Policy

DavidIllsley: in most cases a client may not understand the assertion, unless you mark it as mu

<David_Illsley> if it's not mu and you include AddressingRequired you'll get an alternative without it which will interoperate

TRutt: people may resue this in ways we don't define, I don't want to use two assertions

<GlenD> the assertion/extension simply has the meaning "use addressing". The optionality or not comes from the context (WSDL or Policy). I don't think that's hard.

<GlenD> (maybe it is tho)

TRutt: if we change the semantics without the namespace we will break existing implementations

<gpilz> I thought Chris Ferris pointed out that wsdl:required has nothing to do with wether the use of the feature indicated is required or not

<gpilz> wsdl:required simply means that you must understand the extension in order to understand the associated WSDL

<GlenD> wsdl:required means you must understand and abide by whatever the extension means.

MrGoodner: confused about what we're talking about, previous discussions were about leaving existing implementations alone, I don't believe the proposal we just accepted changes existing use of UsingAddressing.
... we need to concentrate on what Bob asked - which document does this go in

<GlenD> you can't "understand" and ignore extensions, unless the semantic of that extension is written to be optional, which would wsdl:required a little weird.

<GlenD> it's like soap:MustUnderstand

Katy: we've already implemented this, but it wasn't a final draft of the spec, so future implementations will only conform to the Rec, we're not tied into the spec yet

Document Name (cr37)

Bob:options for packaging

... into a single "Addressing Metadata" document or a separate document for the WS-Policy assertions

nobody wants another document

Tony: does changing the name send us back to LC?

<GlenD> +1 for Addressing Metadata

Bob:we're going back to LC anyway

RESOLUTION: hearing no objections, WS-Addressing Metadata is the name of our document

Namespace (cr38)

Anish: CR document is stable, namespace won't change, but it makes no sense whatsoever to have two assertions to say the same thing
... we got rid of the anonymous marker, can't we lose the UsingAddressing marker too?

MrGoodner: unhappy about invalidating implementations by removing this feature (not at risk) for no good reason, in all the previous calls we've focussed on leaving this marker alone, this seems like a last minute descision

Anish: it's not abitrary, you can continue to use the published CR namespace and it'll work, but saying we won't change the CR document is silly

plh: agrees with Marc, we shouldn't change the meaning of UsingAddressing under our namespace policy, but we can remove it

Katy; we need a policy marker and a WSDL marker, let's keep the one we've already got. Having two different markers is fine, using a different marker (possibly in the same namespace) is a good way forward

MrGoodner: we use the marker as a policy assertion

<gpilz> +1 to Katy

discussion on implementations which depend upon wsaw:UsingAddressing as a policy marker

MrGoodner: (to Anish) why do we need to define the intersection between these mechanisms?

Anish: the two mechanisms can say the same thing

Tony: in conflict

MrGoodner: not going to happen with current implementations

plh: are we telling people to use UsingAddressing or Addressing required? If it's the latter, why do we need to provide UsingAddressing as well?

Katy: two markers means everyone has to implement both, using the Policy marker seems to be a good way forward

Gil: two policy assertions that do the same thing isn't good, it's unfortunate that some people have built their implementations on the CR, keep it as an extension, remove it as an assertion

MrGoodner: we've taken a sudden turn. Cutting UsingAddressing means the namespace needs to change

Tony: mark it as deprecated

plh: in the first version of a Recommendation?!

MrGoodner: point is it is being used, there are shipping products using this

<MrGoodner> http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#id2263339

Tony: has no problem changing the namespace
... probably not the first/last time there will be time for implementations to migrate from CR to Recs

<anish> didn't we have a namechange policy somewhere?

Katy: changing the namespace is OK, but mean getting rid of UsingAddressing? seems like we've four options on the table, I'm confussed!

TRutt: changing the CR namespace, taking the marker Anonymous out of the existing namespace has already likely broken something

Bob:any objections to using a new namespace for the new elements

Pauld: object to having two namespaces

Tony: anyone object to new namespace for all the elements?

DaveH: seems cleaner

no objections

Bob:OK, we're going to use a new namespace for the next revision

RESOLUTION: New namespace will be used for the new revision due to extent of changes

<David_Illsley> can we have a namespace without 'wsdl' in it?

<GlenD> +1 at this point

<scribe> ACTION: editors to create a new versions of the document as "Web Services Addressing Metadata" [recorded in http://www.w3.org/2006/12/11-ws-addr-minutes.html#action03]

<dhull> +1 to David/Glen

<anish> +1 to the change

DavidIllsley: discussionof the name wsa(m|w):Addressing seems to be a good way forward
... we should drop wsdl from the namespace too

plh: why are we talking about namespace prefixes which are meaningless

Gil: AddressingRequired optional="true" is confusing

no objections to rename "AddressingRequired" to "Addressing"

MrGoodner: new namespace is for the next WD, not for CR, right

Bob: yes

MrGoodner: have to talk to our developers on the impact of moving to the new namespace

Bob: are we in a position to close CR33?

RESOLUTION: close CR33 with David Illsley's (and other) proposals

<scribe> Chair: editors to incorporate errata and remove flirtatious text as a second edition

MarcHaldley: might be prudent to wait until we're done with the WSDL binding

MrGoodner: others should research on the impact of removing UsingAddressing

ADJOURNED