See also: IRC log
Present: Marsh, DBooth, Umit, Amy
Regrets:
Chair: DBooth
Scribe: Marsh
DBooth: DBooth, Amy and Umit have contributed thoughts on the list:
Scribe: http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0027.html
... http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0028.html
... http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0024.html
<dbooth> http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0027.html
... http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0027.html
Scribe: 1. Patterns describe *minimal* expected behavior.
Amy: Would like to see 3 combined with 1.
... How do we draw the line for "minimal" and "expected"? 3 is how we draw the line.
Scribe: ACTION: DBooth to combine 3 into 1.
<dbooth> Agreed on new text:
... [[
... 1. Patterns describe *minimal* expected behavior.
... Each pattern represents a contract that specifies *minimal* behavior that
... is expected between the parties.
... In general, the WSD (and therefore the patterns) should only contain
... information that is relevant to more than one party. (For example,
... information that the client and service need to agree on.)
... The clients and services may have
... additional behaviors that are not specified by the pattern. Specifically, a
... client or service may send other messages (to each other or other parties)
... that are not described by the pattern. However, in such case, the parties
... must use other means to agree on the handling of the additional messages.
... For example, a message specified in a pattern as being from service S to
... client A might actually be broadcast to other clients in addition to being
... sent to client A. However, the pattern only governs the agreement to send
... the message to client A.
... ]]
Scribe: 2. Patterns specify parties as variables.
... General approval
... 4. Suggested pattern recommendations
... p1 family recommendation: Adopt p1a:
Amy: Would be nice to propose new text for the spec.
DBooth: Biggest change is specifying parties as variables.
Amy: May mean the cardinality property disappears.
DBooth: In cases where multiple messages are intended to be between the same two participants, we still need it.
Amy: But we could remove the distinction between p6 and p8.
... Cardinality has the same kind of situational requirement that identification of participants has.
... Not necessary to identify participants in input-only.
<dbooth> Cardinality is important if it is between the SAME two parties.
... Because they need to agree on it.
Amy: David's proposal in #2 is that when an exchange has a sequence of two or more messages the variables must be specified.
JMarsh: Summary: Cardinality is important to distinguish some patterns, but not necessarily relevant for all patterns.
<dbooth> There are two kinds of cardinality: (1) multiple messages sent from party A to party B; or (2) multiple messages sent from party A to multiple parties. The first kind is important to capture in the pattern; the second is not.
Amy: Don't have a way to talk about node identity in WSDL - that's the domain of Choreography.
... Would like to see generic addressing feature exposed somewhere.
Scribe: [Scribe is a bit lost here...]
... Amy and David will bang something back and forth.
... ACTION: Amy and David to propose (roughly) what needs to change to introduce properties identifying parties.
... Back to p1 family.
<dbooth> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p1a
Scribe: Adopt p1a. This doesn't preclude broadcasting.
<dbooth> p2 family: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2e
Scribe: Adopt p2e - classic request-response.
<dbooth> possibly p2d: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2d
Scribe: Do we also want to recommend third-party response (p2d?)
DBooth: Question about where the fault should go.
Amy: Doesn't want to recommend it but is happy to use it as an example.
... to the WG.
... Illustrates the value of the information items.
Scribe: Consensus not to recommend p2d to the WG.
<dbooth> p3 recommendation: Adopt as p2e, as described above.
... p4 family recommendation: Adopt p4c:
... http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p4c
Scribe: p4c has cardinality - multiple messages going from S to A.
<umit> The consensus I think is not to recommend p2d unless there is agreement in the WG to add the necessary information items.
<dbooth> p5 family recommendation: Adopt p5a:
... http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p5a
Scribe: Agreed.
<dbooth> p6 family recommendation: Adopt p6b:
... http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p6b
DBooth: May subsume p8* later.
<dbooth> p7 family recommendation: Adopt p7b:
... http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p7b
... p8 family recommendation: Drop in favor of p6b, which can be used by the
... service as p8d under the "pattern specifies minimal behavior" assumption,
... without affecting the clients.
Scribe: Agreed.
... We have two fewer patterns - yay!
... Names?
... Will use the existing (non-numeric) names...
Scribe: We don't have a single recommendation on fault rules, but can communicate some info.
Amy: "fault replaces message" when there isn't a designated response message (?)
... Likes the idea that we could have a single rule set, but it doesn't appear possible in practise.
... Willing to let p6 subsume p8 if I can replace the fault rule.
... So both fault rule sets must be visible.
<dbooth> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.html#fault-rules
Amy: Need to add participant identity to these rules.
... Happy to recommend that we add more precision to the rule sets.
David: don't have consensus at this point.
... Which patterns need different rules?
Amy: At this point, we need "no fault" (in-only, out-only), "fault replaces message" (others)
... Would like to see an output-only pattern with "message triggers fault" and output-input with "message triggers fault".
... Might at some point expose fault rules in the WSDL.
... If that doesn't happen, we'll need different patterns (as extensions).
... Keeping the rulesets makes these extensions easier.
JM: Are we recommending keeping the existing three rules in the spec although we only use two of them for the built-in patterns?
David: Makes a pitch for having a single rule.
Amy: HTTP binding can't do "message triggers fault".
... I've changed my position from "message triggers fault" as the only thing we need, to "fault replaces message", because of feedback I've gotten about HTTP.
David: Doesn't buy that there are two ways to think about fault - all faults are triggered by a message in some way.
Amy: If we had input-only with a "message triggers fault" rule, how is that different from request-response?
... "no fault" is much more precise for input-only and output-only.
Scribe: We should illustrate different fault rules on a single pattern (output-only) to show how they work.
Scribe: Expected deliverables to WG:
... 1) presentation on what we've learned.
... 2) suggested improvements to the doc (e.g. remove 2 patterns)
... 3) list remaining questions
... The session will (hopefully) bless task force recommendations, and figure out how to dispose of remaining questions.
... ACTION DBooth to prepare presentaiton.