RE: [ws-caf] minutes rough draft

["Newcomer, Eric" <Eric.Newcomer@iona.com>]

A typo in the minutes - shall I just corrrect it and post them?  There were some cases where Greg was listed as the speaker when it was me (Eric).  See >> below.

 

Thanks,

 

Eric

-----Original Message-----
From: John Fuller [mailto:jfuller@wernervas.com]
Sent: Monday, January 17, 2005 12:10 PM
To: WS-CAF
Subject: [ws-caf] minutes rough draft

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

 

>>Eric 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.

 >> Eric 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

 >> Eric 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

 >> Eric Greg: traditional XML allows passing content

that isn't understood or recognized

Tony to submit the issue to bugzilla and working argument

 >> Eric Greg: action to get editors together to discuss action items