[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: July F2F Draft Minutes
combined minutes attached
WS-CAF meeting, Oracle, July 12 - 14 2004 morning ------------------------------------------------------------------------- Role Call: ------------- Members: Mark Little Malik Saheb Tony Fletcher Peter Furniss Alastair Green Krishna Cheemalamarri Guy Pardon Eric Newcomer Martin Chapman Simeon Greene Jeff Mischkinsky Greg Pavlik Pete Wenzel Doug Bunting Ramesh Nagappan Jan Alexander Observers: Goran Olsson Meeting is quorate until qurom counts requested. These have been clearly maked. Agenda Review: ----------------------- http://www.oasis-open.org/apps/org/workgroup/ws-caf/event.php?event_id=4981 Minutes: ----------- Recommend adoption of June 21 minutes: http://www.oasis-open.org/archives/ws-caf/200406/msg00061.html Motion Passed ACTION: Alistair to post minutes from July 5. Issues List: --------------- Issue 14. Discussion: Should be a consistency issue across specifications. Referencing specs would inherit from the base type. We need to define some conventions for handling definitions, and a consistent schema for hierarchically based specifications. We were going to allow the referencing specifications to define this and specify uniqueness, but we didn't carry it through consistently. We want unique status values, two proposals, one where we just use a namespace, and as Keith Swenson proposed you have a vanilla string with no namespace, but it's implicit in the string. Simeon prefers the namespace, as does Martin. Mark prefers using the namespace approach. But in the discussion it turns out that there's broken XML inasmuch as there's a value definition that needs to change but can't. So the Fujitsu approach seems more attractive in the end, with a generic string and the specification defining acceptable values. Could have a namespace attribute. Summary from Simeon after the discussion and whiteboard session: Define a status type as a string, and it's up to the referencing specs to validate (i.e. values taken outside schema validation). Can have a namespace as an attribute on the status type for qualifying the values. Motion by Simeon, second by Malik: Define a status type as an extension based on string in the schema. The value will not be defined in the schema but in the referencing specifications. There's an attribute on the types that specifies the namespace so the values can be uniquely qualified. Mark discussion: there's also the completed/completing status. If this solution is good for status, should the same solution be followed for completion status. Greg: completion status is an optional string in a message. Martin: Should be two different types but the same rules for each. Greg: Do we really have different status types now for completed and the general status? Mark: May be situations in which they are the same but other cases in which they have the same name but mean different things. Martin proposes a separate proposal about completing status - Mark agrees. Motion carries, one negative vote. New Motion: Define an identical type for completion status. Mark makes the motion, Malik seconds. Discussion? Tony - why do we need two? Mark: Happy enough with what Tony proposed - "completion command" instead of status for completion. Amendment to Mark's motion to define type for command instead of completion status. Completion status is now completion command but follows the same content model as status, which is a namespace-qualified string. Motion carries, one negative vote. [Can be a qname, in clarification to Doug, explanation of the morning's work.] Issue 47 Still an action pending on Martin to discuss with Oracle security experts to get an idea for a proposal. Issue 59 should be closed since the specification doesn't use ALSes any more. Doug brings up Issue 58 - generally improving the diagrams. But let's close Issue 59 first. Malik makes a motion to close issue 59 with no action. Tony seconds it. No objections, motion carries. Issue 99 We need to do this but haven't the time at present. Leave open. Assigned to editors. Need to discuss timeline as part of the general planning around document completion. On to Bryan Murray's issue list. Discussion includes Bryan and reviews changes in the editor's draft (0.4). Martin: If the spec isn't unambiguous about the order of messages, something needs to be added. Greg sends editor's draft to the group for discussion, including comments/flags for Bryan's issues. We don't assume reliable messaging but it could be layered. Note that Mark's text qualifying Section 2.1 about reliable messaging (Draft .04) is ok. Martin: Brian Murray [see .04 draft of WSCTX.doc] section 2.2] made a comment about the wsctx wsdl only being partially normative. The current context wsdl only mentions one-way messages. Is that Normative? Mark: In New Orleans we decided that the one-way messages would be normative and request-response would be for a later version. Martin: The spec should say “primarily uses one-way messages with callbacks”. Greg Pavlik: Not primarily, but entirely... all the messages, operations and bindings are one-way style. Martin: The specs should say “one-way operations with callbacks”. This is prescriptive. Other binding styles are possible, although they may have different acknowledgment styles and delivery mechanisms. Martin: [section 1.3 of WSCTX.doc version 0.4] see comment mcl4-mcl6. Check with Greg who wrote this paragraph. Greg: Figure numbers are incorrect... for example Figure 2 should be Figure 3. The text that includes mcl4 should actually be a figure – figure 2. Make sure the example is a coherent unit of text. Martin: [reads mcl7 of WSCTX.doc version 0.4] Regarding addressing spec. Greg: [points to section 2.3] the spec intentionally does not specify how to do callbacks. Martin: The spec needs to mention what assumptions are to be made with regards to addressing. Martin: [reads mcl8 of WSCTX.doc version 0.4] who objected to this? Mark: unique is unique... no need for “globally unique”. Eric: It's not necessary to say “globally unique”. Martin: Votes to remove the phrase. Doug: It's not the scope of uniqueness it's the scope of this particular id. Martin: [clarifying Doug's point] the id's only needs to be unique in time? Meaning it can be reused. Greg: Uses a bank analogy to explain problems with reusing a unique id in any given time frame. Ex. The transaction id in a bank transaction should never really be reused. Martin: Add a footnote or leave it. Mark: Leave it. [Vote: getting rid of “it must be globally unique”. Result: carried (5 for, 1 abstain)] Martin: [reads mcl10] If there are ordering dependencies they should be part of the description of the operations. Action: Where an operation has dependencies, ex., a complete operation depending on a begin operation, it should be described in the spec. Martin: [after some discussion] The behavior is undefined. The client is free to do whatever it wants to do. Action to the editors: put text into section 2.3 for unsolicited responses. Martin: [reads mcl12] Mark: This is addressed by the assumptions we addressed earlier in regards to reply-to. Martin: Changing the context part of the primer. Once we get the committee draft of the context spec we will change that section of the primer. Doug Bunting: Explains problems currently experienced by WSRM's ServiceRefType. WSRM wishes to add a bare uri element that is basically a fall-back that does not rely on any specific addressing specification. Martin: Should our specs refer to the WSRM type (for ServiceRefType – see wsctx.xsd)? The benefits would be that we wouldn't need to redefine the type. Greg: But the base uri needed by wsrm is only needed for reliability semantics? Doug: No. Martin: Are we going to reference what WSRM is doing? [discussion on the semantics of adding a bareUri element to ServiceRefType] Martin: Revisit this for Aug 2nd conf call. Martin: [section 5.2, 2nd sentence] “A begin can be modeled as the first Web service in the Activity to register itself.” Alistair: should be changed “A begin is therefore the first operation in an activity to use ws-context”. [discussion of whether an activity is properly defined by the spec] 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. 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 at: Discussion followed about the value of the demo to showcase context services. The demo was deemed a valuable Several suggestions were made to improve the demo. Chair recaps work. Schedule is on track. 17:15 motion to recess until Wednesday 9:00. Some pre-meeting agenda bashing, what will be the most effective way of getting started on ws-cf, especially given the changes to ws-context. Logistics/ws-context schedule: We've had a successful meeting - need to have another go-round, editors' draft, review There is still an issue-to-be-submitted from Alastair. To be put on agenda for next phone meeting. Martin suggests a target for a document for vote in first week Sept Alastair - need to have the text 2 weeks before a vote Martin: intended category of this document - committee draft would seem appropriate current meetings schedule: various patterns of drafts considered. Conclusion: No call on 19th July. 2 August: submit and resolve all outstanding independent issues (addressing issue/alignment with ws-rel may still be open) (meeting confined to context matters only) 9 August: circulate 0.5 draft containing all issue resolutions (from now till circulation of voteable, all are expected to carefully review the draft and submit editorial comments, editors polish text to produce draft to vote for CD) 16 August - normal meeting 23 August: circulate candidate draft 30 August: - normal meeting; initiate vote to approve candidate as Committee Draft 6 Sept: (7 days from vote opening) vote concludes Next face-to-face: Possibles: Brussels - OASIS plenary week - October 4th. Prague - same week Dublin - same week Prague chosen timings considered: 4, 5th all day 4 pm, 5, 6 am 5,6 all day preference vote of those attending here: Conclusion: 5th, 6th,all day Further out: dec/jan, probably east coast (oracle mt laurel ?) (pattern up to then: Boston, Paris, New Orleans, San Francisco, Prague ) 2. Coordination Framework How to bootstrap work. Martin: WS-context has changed, and there is a need for a revision of it Also need to have general discussion on model and cf as a whole Greg - things are simpler now before: client/app <-> context service <-> als this had problems on the cs:als interactions, what had to be kept cf was defined as an als - als is also a cf, so cs:als/cf interactions had to be dealt with complete to cs with cf - there is a registration exchange that allows communication through the tree (though its up to the coord pcol whether that is used) after: (i.e. now, post NO) c/a <-> context service, how does cf how to the express cs : cf relationship what was an als is now in a sort of inheritance relationship on cs ag: could use the cs mechanisms, extended/overloaded to tree build (the begin+context) but with cf it's suggested that a different tree building mechanism is used greg: not the way existing transaction systems work - nesting is tied to demarcation api, enlistment is internal/invisible the discussion continued greg, martin: distinction between relationship between participants and relationship between activities. participants are members of an activity sub-activities (nested a) are a particular kind of participant ag: consider a tree of things and interposition addParticipant builds trees. these could (but need not) load the parent-context fields. If they do and begin+context is used as well, then we have two ways of tree building - or there is another way of holding the trace Martin: depends on type of thing added - use one if it is an activity, addP if not alastair: as with WS-C, cf doesn't currently allow general tree building, with no hierarchy. Dynamic commit (as the general movement of the coordination point) also can't have differential coordinate to subsets of participants WS-C doesn't have the "active" parts that are in ws-cf - only the tree building (registration, address exchange). this is a better split of responsibility - the higher specification should be responsible for the demarcation, completion and coordination signals a tree-building p'col is useful. greg: context has virtue as activity concept, apart from tree-building activity has lifecycle characteristics - they begin, they run, they complete martin: if we make ws-cf not use begin, complete etc, and only use the context, then we've messed up greg: we can extend these, cf adds semantics to the ws-ctx begin, complete alastair: e.g. dynamic commit wouldn't use coordinate or complete - the completion of the transaction uses other signals. consider also an upcoming cancel (greg: or timeout expiry) which would also cause completion greg: what proportion of higher specs would NOT use complete etc. martin: no point in a generic mechanism that nothing uses. Choreology list of issues. Martin can choreology put these into bugzilla ? Better to treat these as inputs to the editors revision /alignment of the ws-cf specs. Editors: take into account the choreology comments as part of the revision of the ws-cf to align with the changes in ws-context. Some of the comments may survive this and then should be entered as issues proper. Back to cf concepts. greg: asks alastair if e.g. open-top 2pc pcols can't be supported by cf/ctx alastair: can be supported, but would be constrained or have to re-write the rules for e.g. complete ... could have overloading of coordinate, complete, which in some cases triggered the underlying complete message/signal Martin: would like to see an analysis of the known candidates (txm's 3, btp, ws-tx's 2) and whether they would use/be comfortable with the ws-ctx complete, ws-cf coordinate. Impact on ws-ctx complete and ws-ctx timetable. try and get some finger-in-the-air as to whether the use of these is never, rare, common, usual, always. Informal action point: omnes/volunteer Motion to adjourn: 12:10 pdt.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]