minutes rough draft

[John Fuller <jfuller@wernervas.com>]

December 6 minutes were approved (greg moved, tony seconded, no objections).
We discussed Tony's issues from the wscf editors draft.

Here are our comments, presented as a short play, excluding the interlude about the
Hapsburgs from Alistair.  The actions are bold, as actions should be.

79825 Comment: the CAF Architecture, Adding the diagrams from Dublin
Coordination Framework the best working document for laying out the
architecture.  Unless there is a separate architectural document, perhaps
the best place for clarification.
Diagram to clarify the components and communication
Martin: We agreed not to work on Primer until after specifications
Editors agreed that adding the diagrams would be useful
To progress the diagrams perhaps temporarily include in CF
Scope of diagram?
Tony:
just showing coordination framework and context
or as in Dublin show where referencing specifications fit in
The primer is descriptive rather than normative, whereas if it's in CF
it would specify the model normatively
Action for the editors to include the diagrams in the specifications?
Martin: WS-Context should have a basic diagram
CF should show how it builds on Context
Greg: Currently no place for architectural diagrams
Tony: overall view in the primer is fine
Action for the editors to include appropriate diagrams in the specifications
then include them in an architectural diagram?
Separate working draft copies of diagrams?
Alistair: clarify which diagrams as output
   Greg: generic action to the editors to take diagrams from Dublin,
find the best place to include them in the specifications
John: one argument is that it makes it easier to version things
Implies we will revisit WS-Context, editors may look at possibility

79824 Comment: Add message parameter tables
Editorial.  What are the parameters for begun, needed to look at schema,
but schema doesn't provide semantics.  A simple table could give parameter
name and type for each message.
Martin/Alistair: this was agreed to be done, just not done.
Alistair: purpose of each element as well, rather than just message level

79934 Comment: Sequencing in CAF specification
One state chart in Context, but in CF no information about sequencing.
If sequencing isn't specified, we don't know that it is trivial.
   Greg:  Action to the editors to address the requirements.

79948 Comment: AssertionType in WS-Context specification
XML schema for context has an assertion type and an extension including URI
these are used as base type for messages, parameters include a
correlation-id, should be described in the documents
In the coordination framework, in the old version of the schema, the
context assertiontype was extended with qualifiers.
Is it really a useful way of building messages?
In WS-Context the correlation-id was removed?
If it is in the schema, it is a bug.
Alistair proposes the AssertionType is editorial rather than substantive
Is AssertionType just an extension point?
Alistair argues this is poor specification
Alistair provided BTP analogy,
argued base message types cause work without reason
Greg: Generic coordination interfaces?  People leaned toward not.
Endpoint or set of endpoints that could accept assertion types rather
than messages
Martin argues assertion type is still important
Greg: discussions never driven to actions
Doug: why argue against a base type for individual message elements?
Utility so that if in a future spec people want to extend, they can
Perhaps if there was a use case, ex: auditing infrastructure could use
Doug: argument was that having a base type allows the types to be extended
the only extension point
if we want to manually put anys there we can but it enlarges the schema
Tony: one line to add an element, several lines to add extension
In XML you can take a type and extend it
In the transaction protocol specification, restrict ability to do
extensions
In BTP its fairly carefully controlled
some engines have several extension points, generic interface/base type
Alistair: why Any?
Doug: extension without prior agreement
Tony: in the qualifier mechanism, can you ignore or not?
more control in this case
Greg: traditional XML allows passing content
that isn't understood or recognized
Tony to submit the issue to bugzilla and working argument

Greg: action to get editors together to discuss action items