Minutes Tuesday July 13 2004 afternoon

13:00 Meeting resumes

Issue discussion continues..

Issue 136 - Use of begin with context and nested context needs more specification

Discussion on the impact of previously accepted motion.

Martin leads discussion. Will now reference parent context. There is no reference to siblings. Context will contain zero or one parent context. To get the hierarcho the whole

Motion: Change child context to be “parent context”

Change parent context from list to zero or one occurrence and further change parents’ context to parent’s context. Alistair motioned Greg second. No opposed. 8 in favor.

Discussion on tree-building semantics.

Motion by Mark: begin with passed context must set the parent context.

Begin without passed context means no parent context is set. Malik second.

Alistair amendment to motion: delete begin with passed context. Tony second.

Vote: 2 in favor, 6, abstaining 1. Amendment did not pass.

Vote on Marks motion 6 for, 1 no, 1 abstained. Motion by Mark accepted.

This motion closes issue 136.

Issue 138 - can a child context be separated from the parent

Closed as a result of previous motions.

Issue 137 - does dereferencing a context-by-reference always expand all child contexts

Discussion

Peter: context manager can return what it pleases.

Doug: the receiver needs to know what it gets.

Mark: begin return ref or value depending on implementation.

Alistair: spec should be silent on type.

Peter: getcontent return value must return value only.

Issue 137 parked until 133 is resolved.

Issue 133 - context by value and context by reference should be different types

Greg: no change from New Orleans.

Doug: ambiguous cases are few.

Martin: by reference or value should be more like incomplete or complete information.

Doug: flipping back and forth between by reference and by value for a specific context is unnecessary.

Alistair: Context manager is the only service that may change context value others can only observe.

Conclusion: leave issue open for time being to define final text that reflects the consensus. The consensus is basically: if context contains a context manager element then it can be dereferenced and when a context is dereferenced the whole known content of the context will be returned.

Action: Mark to produce text.

Back to Issue 137 - does dereferencing a context-by-reference always expand all child contexts

Discussion.

Doug: Return context must be complete.

Alistair: getcontent should return what was set by setcontent. It should return what it knows.

Alistair: getcontent returns the entire known context

Leave dependent on resolution of issue 133.

Issue 134 - mustUnderstand needs moving and defining

Related to 129

Ballot that previously closed 134 was about soap must understand.

Alistair: 134 should not have been closed.

Motion by Alistair to re-open 134. Second Mark.

No objections. Issue 134 is re-opened.

BREAK.

15:00 Meeting resumes

Issue 135 - participating-services list needs to have defined semantics and modification mechanisms or be removed

Discussion.

Greg: what is a participating service?

Alistair: Not clear.

Eric: the purpose was for a minimal protocol as part of the specification. Now that is handled by referencing specifications.

Peter:

Motion by Eric; since we have extention point. I suggest we remove the participating service list.

Peter second.

No objections. Motion approved. Close issue 135.

Issue 140

Discussion

Alistair: if we use context manager element is not part of this issue.

Martin : how do we use this URL.

Peter: reading from note .4

Motion by Alistair: remove the context URI leaving the context manager as the sole choice.

Greg second.

Discussion.

Eric: a clarification there is now two emerging specifications around. We need to allow for adoption of either.

Vote: 7 for, 0 against, 0 abstained. Motion accepted.

Issue 140 closed by adopting motion.

Issue 141 is dependent on 133. To be discussed once new 133 text is available.

Issue 142

Discussions.

Alistair: there are multiple questions.

Motion by Simeon: change the type of context service from any type to a service reference Type.

Malik second.

Alisair motion to table discussions. Peter second.

Table 2 for, 5 against.

Alistair: the notion of status and the way protocols complete is purely related to referencing specifications. I support having the reference available to query about state.

Even though state would be defined by referencing specifications.

Eric: Speaks in favor of the motion.

Objections none. Motion accepted.

Motion by Alistair: make context service field mandatory.

Simeon second.

Vote no in favor, 5 against, 1 abstained. Motion failed. Field remains optional.

Ad-hoc discussion on the relevance having a completing state. Alistair argues that it will never be observed, instead a transitional state defined in the referencing specification

will be observed.

Consensus: the state active, completing, and completed are important for a modeling purpose.

Action: Alistair to define the relevance of querying state while the activity is in

Between active and completed state, the “completing” state.

Issue 134 again.

Motion by Peter: to remove any references that WSCTX must understand from the context type structure.

Second Alistair.

No objections. Motion accepted. This motion closes issue 134.

16:30 Demo presentation showing interoperable implementations starts.

Presented by Simeon. Slides follows.