minutes from f2f 7-13-2004 morning

[Greg Pavlik <greg.pavlik@oracle.com>]

Morning

Reserved discussion for issues raised by Peter

136, 137, 138 about child contexts first.
Starting with 136: discussion of whether this should actually be the 
child contexts. Greg pointed out that specs may be in error. Alastair 
believes this is part of higher level protocol definition and is arguing 
that it doesn't belong in context: ancestral trail or tree reflecting 
children. Peter: concerned that typed field could be of the wrong type. 
Alastair: needs to be general to context. Eric: doesn't buy the 
argument: this is a general mechanism for representing nesting. Peter: 
doesn't think it should be reflected in the context. When nesting is 
occuring, are the fields sufficiently common. Eric: nice general 
purpose, in simple spec. Alastair: disagrees.

Setting up queue. Peter, Greg

Peter. Believes that 136, 137, and 138 would be answerable by reference 
to spec.
Greg: two points: we did go over use cases. Replication, security, 
transactions (we're all familiar with the latter); shouldn't we simply 
be validating structuring.
Eric: agrees with Greg

Peter is uploading file for 10 minute discussion

"Any construct whose semantic definition is only given in an extension 
specification should not be in the base". Somewhat analogous to 
polymorphism, but not quite. Greg: might this Context not be more like 
java.lang.String? Fully scoped, but semantics are applied with an 
application domain.

Context type: represented as struct.

Alastair: optional is a warning flag. Procedural motion to go issue 1 by 1.

Greg: schema doesn't supply normative rules. Alastair: what if text 
doesn't say optional. Greg:: needs to.

Moving on to 136. Peter on guiding principles. Martin: not sure slide 1 
is wholely clear. Alastair: number of ways to have baseness, so we have 
to be careful.

Mark: we voted to support nesting: shouldn't we just fix to reflect parents.

Alastair: nesting is ambigous. Martin: no it's not. Alastair: do we need 
to have the full tree? Doug: no, only a branch. Greg: by branch, you 
mean a fully directed path? Doug, yes. Martin: that's what shown. 
Alastair: ordering, partitioning, etc., implies a particular use. Why is 
this particular use being given preference?

Alastair: where do we need the whole tree: grid of network elements. 
Greg: I don't disagree, but we have concrete use cases. Why can't we 
support them? Alastair: have heard three views. Doug: Greg and I saying 
same thing. Peter:

Peter: Consider this hierarchy:

a
|
|--b--c
|    |--d
|--e

can you say for all possible contexts what this means? Can it cover 
arbitrary relationships?

Martin: this is only about parent-child relationships.

Alastair motion: remove child-contexts element from the context-type. 
Seconded by Peter. Discussion. Queue: Malik. Alastair. Mark. Eric. 
Ammendments can be proposed.

Malik: does motion mean that concept of nested activity is removed? 
Alastair: belongs in referencing spec. Malik: possibility to do nested 
activity should be present in context service. Would prefer to see 
parent context, but concept of nested activity should be removed. 
Alastair: believes example of why this should be removed. Believes that 
this will be a derived context service that understands nesting. It is a 
property of a higher level extension specification. May be many 
relationships. Shouldn't privilige one deemed relationship: you are 
trying to foresee all possible referencing specifications over time and 
selecting some subset. Believes basic notion of context is an identity 
of activities only.

Eric: believes useful and needs to be preserved but fixed. Generic 
infrastructure is useful. Ex. SOAP headers defined in advance of use.

Mark: proposal: The Context structure be changed to reflect parent child 
relationship whereby the child context is replaced by parent context 
(meant to represent current attribute name in context schema). Spec 
should be updated, to describe that this data structure only reflects a 
linear portion of a potentially tree like activity structure from the 
root to the leaf.

Alastair: point of order. Ammendment delete Alastair's and replace by.

Malik: second

Alastair: procedural motion: may be proposed as counterposed motions. 
Don't need charade.

Alastair: Mark meant to say from the leaf to the root. Doug: 
parenthetical: most narrow to most wide.

Mark ammends "from leaf to root".

Peter off queue: implicit but not stated about begin would fall away in 
original motion. Unclear that CF uses this mechanism. Is Mark proposing 
to revise this? Mark: reaction: change requires newly created activity 
to become the leaf and parent in hierarchy. Peter: should it put explict 
qualification on begin? Mark, is that not a separate issue. Peter, 
trouble is, answer effects how the relationship is understood by 
referening specification. If begin text says nothing, than this violates 
"Peter's first rule" from slidesets. In addition, presence or absence of 
field has no implication for how activities may be related (answering 
Malik).

Doug off queue: ammendment does a poor job of helping Doug understand 
how contexts of multiple types relate in a particular message. Spec is 
ambigous and suggests that there's a way to relate different activities. 
Original motion clarified relationship expression by removing them. Are 
activities in tree of the same type or different types? If different 
types, then nothing

Greg off queue: felt ammendment clarified (though I always assumed that 
Contexts of the same type). nesting is indeed a particular relationship, 
however it may be expressed as a general property as evidenced by the 
original definition of the context manager -- which worked in concert 
with the als. It is perhaps an implementation choice. Second: we want to 
express attributes of context, not just activity.

Goran: agrees with Peter's first slide "semantics that are unique to 
referencing specification should be defined there". Begin should define 
framework for creation. Believes context nesting belongs naturally in 
this specification as an artifact of context management.

Alastair: coordination framework relevant. Nesting relationships should 
be expressed via context.  Coordination framework tree is indepdent and 
does not make use. We have a mechanism artifially forced on referencing 
specification. Or mechanism isn't going to be used by CF. Do have 
specificity that cannot be distilled. Can remove begin, but points that 
functionality belongs in referencing specification. Believes that there 
is a latent desire to bag sets of contexts. Child context wasn't 
intended to do this. Doug: ambiguity in the text. Alastair believes 
there needs to be an statement that they need to be of the same type.

Martin: believes use cases for leaf to parent is useful enough.

Mark: no example for something other than parent child relationships. 
Other specs comparisons, txm and cf, is wrong because they were written 
against older version of specs with other assumptions.

Greg: tree building misleading. Modeling two things with indepdent 
semantics: nested activities, activity participants. Shouldn't conflate. 
Also reflects existing systems.

Eric: from discussion, we can agree that there is ambiguity.Believe we 
should fix spec not throw out

Doug: believe we need to say this is for a single type. Use cases so far 
has been for parent child. Havne't heard reason to have entire trail to 
root rather than immediate parent. What are the use cases for more than 
just parent. Eric, another ambiguity that should be resolved. Doug: may 
want to genericize proposal slightly. Proposing ammendment to 
ammendment: "only reflects some linear portion of a potentially tree 
like relationship between contexts of the same type".

Mark seconded it. Discussion. Does this mean parent only or parent up to 
root without saying "whole path". Doug: original proposal goes too far 
to specific solution. But reflects that we are talking about contexts of 
the same type.

Alastair: ammends ammendment to remove "only" then remove "linear 
portion of potentially tree like". Motivation: let's admit that 
referencing spec defines relationship. Peter second.

Malik: not clear about same type. Transactions nest transactions? Doug: 
two different types would be top level headers.

Martin: partially likes Dougs proposals.

Peter: can remove ambiguity which focuses it to a particular use. Do we 
want to reflect strict nesting. More precise, the less it belongs in 
base specs.

Eric: believes we have moved backward away from clarification. Likes 
Doug's clarification, not Alastair's.

Greg: would like to make motion to unwind.
Voting on ammendment to ammendment to ammendment to main motion.
Ammendment voted down. 1 for, 7 against, 0 abstain.

Jeff has called question on Mark's ammendment. Also have to vote on 
ammendment to ammendment. No objections.
Alastair: clarification voting for, doesn't mean you agree on 
ammendment. 9 for, 1 abstention for Doug's.

Alastair: quorum call before next vote. Not quorate. Martin: proceed 
with recommendations to quorate group.

Vote, on marks ammended motion (child to parents). 7 yes. 2 against. 
ammendment carried.

Vote on motion as ammended. "Retaking same vote" for all intents and 
purposes; voting to change child to parent. 7 yes, 2 against. Net effect 
is what we recommend.

Martin motion to recess for lunch, come back at 1:30.