See also: IRC log
Present: JMarsh, DBooth, Umit, Amy
Regrets:
Chair: dbooth
Scribe: JMarsh
<dbooth> http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jun/0027.html
David: Amy sent out an exploration of variations on pattern 2.
... Pruned down to a list with 2 new patterns to consider.
... David added 1 of these to the doc.
<alewis> p2umci-7
David: The other one was a variation of p2c or p2d or p2d1 (which are equivalent except for faults) + the constraint that A != B.
... Couldn't imagine that A!=B is a constraint we would want to stipulate.
... There are three cases - nodes must be the same; nodes may be different; nodes must be different.
... Sensibile to allow a node to take on as many roles as it likes.
Amy: Not trying to generate new patterns for inclusion, but to see if some criteria provide explanatory power we're looking for.
... In terms of whether we should include these patterns, I'm at a loss.
... That isn't really what my variations document was trying to do.
... We were trying to explore the value of these extra distinctions.
David: Seemed to agree that A!=B doesn't seem very useful.
Amy: Yes, but not clear which use cases are ascendant.
David: Trivial to add.
Umit: What are you trying to do?
... Are you trying to reconcile the variations with David's doc?
David: Yes.
Umit: The biggest distinction Amy has made is in regard to faults.
David: Question came up a few telcons ago - we decided to continue making faults explicit in this doc.
... We might factor them out according to the fault rules later.
Umit: Not sure how certain patterns are useful, but the one identified to be illegal after collapsing.
Amy: You could use a different fault rule, but then it's another pattern.
Umit: Where the fault goes is an important distinction.
... Prevents us from collapsing patterns.
David: Factoring out the rule set is not OK?
Umit: Perhaps. Some of the collapsed patterns might not be useful. But we lose the distinction if we collapse out the faults.
... likes to leave the faults in the doc for now.
Amy: Seems like a way to multiply the number of patterns.
... There are additional patterns. We could define a new set of patterns with a different rule set. But not sure that's too interesting.
... Indifferent to leaving faults in or taking them out of the doc.
David: Should I include p2ci-3?
... Looks like I can leave it out.
<dbooth> 2ci-3: input message source must be different from output message
... destination
... JM: How will the factoring of the faults impact tool generation?
... ... If we collapse how faults are treated, will I care?
... Amy: Yes, you'll care about fault generation.
... JM: In the abstract interface, or in the binding?
... Amy: That depends.
... ... Even if we have req-response we still need to decide whether it should be at the abstract interface level or the binding level.
Umit: Couldn't tell where you were drawing the line. Do fault rules go into the abstract part?
Amy: Yes, but more generally a toolkit needs additional information.
... We haven't gotten yet to the point where we can distinguish between third-party request response and classic request-response.
Umit: Certain patterns you can use today without more info, others might need more info.
Amy: The last set of pattern variations (...) is the strongest set of distinctions.
... If we add these distinctions, do they need to be abstract or in the binding?
... Is it enough for the toolkit to know it's input-output in the abstract part?
David: Usecase UC-1 demonstrates that p2 is not sufficient for certain use cases.
Amy: Not the question. Do we need the info at the abstract or binding level?
... Are the toolkits generating code for abstract stuff, or wait till you get a binding?
Umit: Both.
David: UC1 is about using the abstract part without a specific binding.
Umit: Are you going to get different code from looking at the binding?
... One approach is to hide all the binding stuff within the stub. Another is to wait till you see the whole thing before generating code.
... The latter assumes that incomplete WSDL is not consumable.
... Different companies come with different assumptions.
... Most of the people today seem to be working on the former (abstract only).
... Design WSDL at the abstract level, finally a binding is defined.
... Hints at what kind of client support you will provide.
David: JM's original question: what impact on tools from factoring out faults?
... Do we describe each pattern with it's own fault characteristics, or provide general rules.
Umit: The fault rules are OK. They don't eliminate the presence of faults. Collapsing them removes the distincition about what happens when faults occur.
David: We would have to adjust the meaning of the notation.
... Just because a pattern doesn't indicate a fault, that doesn't mean there cannot be a fault.
... In general a pattern captures certain characteristics, but doesn't prevent other nodes or whatever from existing.
Umit: You can't abstract faults away without losing information.
------------------------------
<dbooth> See Youenn's message: http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jun/0024.html
David: Any wisdom to share?
Amy: In Scottsdale we decided to make WSDL patterns operate at a more fundamental conceptual level than SOAP MEPS.
... Some discussion whether we should ask SOAP to define their patterns in terms of ours.
... Decided "no". They weren't going to change.
... Doesn't change the fact that SOAP patterns are more explicit than ours.
... No attempt to discriminate on our part between HTTP request-response, an HTTP get followed by a SOAP response, and a SOAP request-response.
... XMLP has defined two of these.
... In WSDL we also are dealing with pure HTTP request-response.
... I don't see that we have a significant win in distinguishing those cases.
... Do we need to identify SOAP categories of request-response?
... Can we leave this totally to the binding?
Scribe: David, Umit: Leave to binding.
Amy: There's a certain amount of SOAP r-r that we won't model outside the binding.
Umit: Does it matter to the client? No.
Amy: We don't need to make as many distinctions as SOAP r-r patterns, right?
Scribe: David, Umit: Sounds like the case.
David: Still useful to show correspondence between our patterns and XMLPs.
Amy: Yes, at some point we end up with a pattern (p3) which maps to both SOAP MEPs.
Umit: Equivalencies.
David: Specializations.
Umit: If they map to p3 doesn't that mean two equivalent implementations of the pattern?
... Actually a concretization of the pattern in three different ways.
... When we have a leaf node in our lattice, there may be a specific binding that describes that pattern.
David: Specific binding is not an actual sequence of messages. A sequence of messages conforms to the binding, or not.
... If it conforms to the binding, it conforms to the pattern.
Amy: Can we say we might need some specialized terminology and move on?
Scribe: (scribe missing some chunks here)
Umit: As long as the client has a specific pattern it adheres to, how it relates to XMLP work doesn't matter.
David: We will need to identify the link between our specific patterns and SOAP's.
<dbooth> JM: It would be good of people writing new SOAP specs would reference our MEPs.
------------------------------
David: Drop ones we think are useless, focus on the useful ones.
Amy: Has a problem with categorizing patterns as useful/useless. More interested in identifying the distinctions.
... We have a collection of patterns, without a qualifier for including these patterns. We have request-response and other base patterns from WSDL 1.1.
<dbooth> "This section presents several patterns that either (a) were described in PART2, (b) seemed interesting to someone, or (c) were included only for the purpose of analysis."
Scribe: Are we collecting for a while, then pruning, or are we trying to infer interesting characteristics from the data?
Amy: Is it important to distinguish between unicast/multicast for an output-only pattern?
<dbooth> Umit: Should we allow the fault rule to be separately indicated in the WSDL? E.g., "pattern='foo' faultRule='bar'"
... The same result could be done with "pattern='foobar'"
... ACTION: dbooth to send out email survey on the usefulness of patterns or pattern characteristics in the p2 family