See also: IRC log
<hugo> Scribe: Hugo
Scribe is Hugo
F2F minutes are approved with Hugo's corrections
2005-03-07 telcon minutes are approved too
Chair is going through open actions
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0081.html
<scribe> Chair: this is potentially reopening i053
<Marsh> +1
<anish> +1
<vinoski> +1
UNKNOWN_SPEAKER: any objection to making the change?
<dhull> +1
RESOLUTION: Umit's resolution is accepted
Anish: I wanted to propose to split the schema for Core and the SOAP binding
Marc: things like @isReferenceParameter, @retryAfter, etc. would go into the SOAP binding schema
Gudge: I actually started with several schemas
[ discussion about whether to have 1 or 2 target namespaces ]
Anish: I prefer to have them
split and with different namespaces
... I see Core and the SOAP binding as independent
Dave: I'd like to keep it simple
Anish: the tools can deal with it without any problem
Dave: but humans don't; this is small enough to keep it all in the same namespace
Anish: what if we want to rev one the SOAP binding?
Dave: you can do it
Anish: but we would need to rev a schema which holds both definitions
Dave: do you really think that we would rev only one of them?
Anish: why split the documents then, and not the schemas?
Dave: I don't like this idea that every document has its own namespace and its schema
Chair: this seems mostly
editorial
... is anybody feeling strongly about that?
[ silence ]
<inserted> Chair: we will stop discussion here for now then
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0100.html
[ Dave describes issue ]
Jonathan: if I had a pattern with
reply, fault, alt-reply, what would people do?
... people could add another element for alt-reply
Dave: let's remove ReplyTo and FaultTo then
Gudge: those 2 hit the 80-20 point
Dave: I think that we're tilting very heavily towards request-reply, and not really enabling all patterns
Paco: you're proposing that people can extend without putting a 'wsa:' in front of it
Dave: I don't understand the
status of MAPs
... they don't seem to be reified anywhere
... I don't see what section 3 is adding
Paco: I don't agree that section
3 is limited to request reply
... also, I think that this sentence from the charter just
means that these headers could be used in different
contexts
DaveO: is your concern that our MAPs are not reusable except for req-resp?
DaveH: yes
<anish> searching the current core ed draft and it does not talk about MAP extensibility
DaveO: suppose I have my 3-message interaction pattern; couldn't the properties be reused and then add a 3rd property for my 3rd message?
<marc> see last sentence of section 3.1
DaveO: if the 3rd header wasn't understood, FaultTo would be used to send back a fault
<marc> "Note that each of the element information items described above allows attribute wildcards for future extensibility."
<anish> but that is only about attribute wildcards
<anish> i cannot define another element which is a 1st class property
<uyalcina> I agree with Anish, perhaps we have an editorial problem
<marc> Well, you can you just need to write a spec for it
DaveH: this all came up when
thinking about setting default values to the reply
property
... I think that this is very specific to a particular
interaction, and shouldn't be part of the core
<uyalcina> the question is whether you are allowed to write a spec for them or not.
<anish> even if i write a spec, it is not part of the MAP. For example, WSDL component model is extensiblity, if i write a spec, i can make a new component and make it part of the WSDL component model
<marc> what's to stop you creating a new one ?
DaveO: it all depends on the importance you give req-resp
<uyalcina> the wording does not necessarily appear to allow it
<Marsh> You mean, it's not part of the Core WS-A MAPs as defined in the Core WS-A spec.
<anish> the words seem to say that MAP wrt to element extensibility is closed
<uyalcina> I agree with Anish there
DaveH: accomodating req-resp is fine, but why aren't other patterns treated equally?
<anish> jonathan -- i don't mean that i should be allowed to define "core
<marc> we don't define a container for MAPs so how can we define element extensibility for them
<anish> " properties but that MAP should be extensible for elements
DaveO: we are basically saying that req-resp is part of the core
DaveH: I think that this is closer to the WSDL binding
<anish> marc -- that may be a problem and perhaps we should leave it alone. All I wanted to point out was that I can't define an 'alternate reply' property which is part of MAP.
<anish> MAP does not allow that
Glen: [ missed by scribe; sorry ]
<mnot> Glen asked whether this could be addressed by some text around the properties, rather than changing them.
DaveO: if there was some text that showed how to use our spec with another pattern, would that satisfy you?
DaveH: possibly
Jonathan: I don't understand what we could do that could be automatically handled by processors that would be any different that you would get with our status quo
DaveH: section 3 is: "now that you've got EPRs, here's what you can do with it"
DaveO: I see this as WS-Addressing basic functionality
DaveH: to me, either we need to show how to support complex patterns, or we should change the spec
<marc> to echo DaveO, effectively the SOAP Header is the container for MAPs and that allow all sorts of element extensibility
DaveO: maybe the notification pattern example we received would be a good example
DaveH: when should you reuse?
DaveO: if you do things that look
like faults, FaultTo should probably be reused
... I would like to have these things as reusable as
possible
... we should make sure we don't preclude extension
DaveH: one clear way to get this is to give ReplyTo and FaultTo hardly any particular semantics
Chair: so you'd like to have some text pointing that there is some extensibility possible, possibly with an example
<marc> "Note, however, that reply messages may be sent as part of other message exchanges as well, and are not restricted to the usual single Request, single Reply pattern, or to a particular WSDL MEP. The contract between the interacting parties may specify that multiple or even a variable number or replies be delivered."
DaveH: the above text is fine, but is lacking an example
Marc: what kind of thing are you
looking for? we are going through all the WSDL MEPs and showing
this
... are you suggesting that we should give these tables as an
example of extensibility?
DaveH: with rep-resp, the semantics are defined both in Core and in the bindings
<plh> scribe: plh
Gudge: you can define any element to be of type EPR, why is it not enough?
DaveH: with the extensible story, we're defining exactly request/reply MEP.
Gudge: because of the charter...
DaveH: yes, and they build on
facilities from the Core. If I define my own MEP, I don't have
those facilities
... I'd like to show how to extend addressing
Anish: if we do go along the lines of DaveH, we don't loose anything.
MarcH: but what would it look like?
<uyalcina> that would be a very good addition Marc.
DaveH: I still would like to see more of a good description of how to use the properties besides the resp-req MEP case
<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0019.html
Chair: we already covered some of this discussion here. we could improve the text in the specification, with an example.
<dorchard> +1 to say that an example is "editorial"
Anish: in the resolution of 42, it's extensibility of EPR, not MAP
Chair: no, it's not
Anish: that's not how I interpret the resolution
<mnot> s/MarcN/Chair/g
DaveO: we could prove it's extensible
Chair: could we do during LC or
CR phases?
... we could put this on hold until we discuss how to move to
LC
<scribe> ACTION: DaveH to work with the editorials to clarify issue 42 with regards to extensibility [recorded in http://www.w3.org/2005/03/14-ws-addr-minutes.html#action01]
Tom Rutt's proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0066.html
[Tom summarizes his proposal]
MarcH: it implies that replyTo and faultTo are always there, i.e you always need a messageId
DaveH: not completely sold that a missing fault should default to the reply. If I have a replyTo and a From, one can argue that faults should go back to the From.
Gudge: concerned about all messages having a reply endpoint. there must be some messages where there is no reply endpoint. Are we going to add something to express this?
Tom: this could be an editorial
issue.
... messageId being required is not in my proposal.
... we're talking about properties and default.
... the abstract definition of reply endpoint doesn't have to
be changed. still need to discuss fault endpoint
Hugo: agree with DaveH re reply/from. if we default to anonymous for replyTo, the replyTo propoerty is always set, thus requiring messageId. not sure if the anonymous property brings anything. also could define an "unreachable" property in case you don't have a reply endpoint
Tom: I'd like to withdraw proposal 3. proposal 1 and 2 matter.
Paco: my concern with proposal 1, it eliminates the possibility of having no reply endpoint. I think it is a lost of flexibility.
<Marsh> +1 to Paco
Paco: you do have a no replyto case.
Tom: confused. if there is no response, there is no reply, where is the problem?
<TomRutt> The messageID is the signal that a reply is expected
<swinkler> Tom, does that mean I can't include a message id in a message that I don't expect a response...
DaveH: I don't think the messageId could be the signal that a reply is expected.
<swinkler> +1 to DaveH.
<uyalcina> I would agree with DavidH that presence of messageID should not be overloaded
<pauld> could use messageId as sequence number on a one-way messsage ..
<uyalcina> why not? That will allow composition in some other layer...
DaveH: if I'm advertising a req/resp, others can always do what they want regarding the response, I could also ignore it if I wish.
Tom: still like proposal 1 and 2. not sure I understand Paco's point.
Hugo: re no reply point from Paco. If you're expecting a reply, you need to provide a reply endpoint. If you don't expect, there is no way to say that you don't want one.
<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0074.html
Hugo: DaveH made a proposal to strip the semantic of reply to not a lot of things. "a reply endpoint is where you put the address for reply". even if you're expecting a reply, replyTo is not mandatory. If you don't want to have one, we could define a proposal for that.
Paco: I'd rahter close the issue with the clarification a the defaulting of replyTo when absent, otherwise I would close the issue with no changes. If we don't go that way, we'll need to define a uri for no-replyto.
DaveH: we could add " If this element is NOT present and a reply is expected ..."
<hugo> +1
Tom: the receiver would have to know if a reply is expected. Paco would like to have a way to express no reply at all.
Paco: I want a "no value"
instead.
... but I'd rather with the current status quo
Gudge: it seems the proposed optimization is different from what we choose for wsa:To
DaveH: could we move this into the WSDL binding and leave behind a minimal statement?
Paco: I don't think so. the req/resp pattern is not limited to WSDL req/resp MEP.
DaveH: so any conceivable
req/resp MEP will have this semantic
... we're trying to anticipate any possible situation in the
Core, but we do only know WSDL for the moment.
<Zakim> hugo, you wanted to clarify as the person who raised the issue
Hugo: originally, I wanted to sync reply and fault handling originally.
<hugo> s/originally\./the same way/
Tom: I want the optimization available for HTTP
DaveH: I do have a proposal on what the core would look like without the WSDL binding specific stuff
<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0074.html
Chair: who is in favor of the statu quo?
<Marsh> Status Quo please
<pauld> +1 to status quo
<TomRutt> in favor of dave Hull direction
Paco, Gudge, Umit, Steve Winkler, Bob, MarcH
<swinkler> +1 to status quo
<MSEder> status quo
<dhull> +1
<hugo> +1
<mlpeel> +1
<TonyR> +1
<swinkler> plh, that was steve winkler, not steveV.
<TomRutt> Tom in favor of d hull approach
<vinoski> abstain
<Pete> abstain
<anish> abstain
<bjarlestam> abstain
<yinleng> abstain
<prasad> abstain
status quo: 7, 5 for moving from Core to WSDL, 6 abstention
<TonyR> I can see 7 abstentionss in IRC
<vinoski> i also don't know yet
status quo: 8, 5 for moving from Core to WSDL, 6 abstention
<Zakim> hugo, you wanted to propose to just close the issue
Hugo: how about closing the issue with status quo and moving on?
Tom: we could close it with proposal 2
"If this element is NOT present then the value of the [fault endpoint] property is the same as the value of the [reply endpoint] property."
<dhull> +1
Jonathan: don't like the exact
mechanism. proposal: "if no fault, send fault to the
reply"
... so we don't have a faultto property
... if you interpret the precense of the faulto property, we
keep that open
<scribe> ACTION: Jonathan to write a proposal for faultTo defaulting [recorded in http://www.w3.org/2005/03/14-ws-addr-minutes.html#action02]
Chair: we'll vote on this next week