See also: IRC log
Present: Amy, Philippe, dbooth
Regrets:
Chair: dbooth
Scribe: dbooth
Amy: Critical issue for Tibco: Pub/Sub is characterized by a single output followed by 0-n inputs.
... A single message is sent, but it is receive by 0-n parties.
... Each listener may choose to respond or not.
Scribe: In terms of looking at the pattern, it needs to be characterized as single msg out, multiple msgs in.
Amy: Graphic for #8 looks right, but XML looks wrong.
dbooth: so the "<output>*" is the part that's wrong?
Amy: yes
... The Patterns document [ http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.xml ] does not model multicast, but I need to do multicast.
... When I wrote the description of pattern #7, I couldn't distinguish between multicast, unicast and don't-care.
... If patterns include the multicast/unicast/don't-care distinction, then in pattern #7, the first message is supposed to be multicast.
dbooth: When I realized that the pattern #7 that I defined in the meps-vs-iops document wasn't what you wanted, i added pattern #8 which hopefully is what you want.
Amy: I'd rather you modify #7 instead.
... Your pattern #7 doesn't match the Pattern doc "2.8 Multicast-Solicit-Response".
dbooth: It was intended to match precisely that pattern, but I may have read that definition differently than you.
<Philippe> (out, ((in , out?), ifault)*)
Philippe: I tried to model 2.8 in IRC (above). Is that correct?
Amy: Yes.
<Philippe> (out, ((in , ofault?), ifault)*)
<alewis> OUT, IN*
dbooth: It sounds like I made an assumption of "conservation of messages" where you did not.
<alewis> OUT, ((IN, OFAULT), IFAULT)*
Amy: Yes. I think conservation of messages makes pub/sub impossible.
<alewis> OUT, ((IN, OFAULT), IFAULT?)*
... OUT, ((IN, OFAULT?), IFAULT?)*
... OUT, IN*
<Philippe> out, (in , ofault?)*, ifault*
Amy: It's easy to say that any action could trigger a fault in the opposite direction.
<alewis> OUT*, IN*
... OUT+, IN*
dbooth: The "<output>*" that I wrote in #8 is misleading. I should remove the "*" and replace it with something like: "<outputMulti>"
... or maybe just "<output>"
Amy: So the difference between #7 and #8 is that #8 is multicast?
dbooth: yes
Amy: We're planning to use Pattern doc 2.5 (mep-vs-iop #4) as multicast.
... If you distinguish between #7 and #8, then you should also distinguish between #4 and #4-with-multicast.
... The binding indicates whether it's multicast or unicast.
... By the time we read the complete WSD, we should know exactly what MEP it is.
... If you're running over HTTP, that's the only thing the binding supports.
... THe question is: Do you need that info earlier, in the abstract part?
... If so, then the current definition is insufficient. We need to add the sender and recipient.
... If each message is characterized by both its sender and receiver(s), then that also adds the notion of multicastness.
dbooth: Agreed
Amy: So if we add the sender and receiver info to the abstract portion, that should disambiguate the possible MEPs.
dbooth: Agreed.
Scribe: ACTION: dbooth to update meps-vs-iops to correct the "<output>*" to "<output>".
... [Meeting adjourned]
<Philippe> hi gudge
... we missed you at the MEP call
<Gudge> well, I didn't feel like I'd contributed constructively last week
... so I thought I'd give it a miss this week
... also, I'm not feeling 100%
<Philippe> I think we managed to understand the misunderstanding
... and that is a great improvement
... two more weeks at most and we might reach the goal
... hope you'll get better soon
<Gudge> thanks