See also: IRC log
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
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: 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
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
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
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
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
Tony: has no problem changing the
... 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
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
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