Dear
Mark and others,
It is
my personal opinion that AssertionType is useful as shorthand type definition in
some instances - basically those cases where a message is just a name wrapping
an extension point. Apart from this it does seem to be just a historical
hangover.
Below
you state 'Certainly we've got users who would find the
removal of that facility a step backwards'.
Given that it is very easy to add an any to a message structure to give an
extensibility point what facility would we be loosing if AssertionType is
removed?
Best Regards
Tony
A M Fletcher
Tel: +44 (0) 1473
729537 Mobile: +44 (0) 7801 948219
Apologies for not being there. Sounds like it was
an interesting call. My only comments are that I believe we should keep
AssertionType for all the positive reasons that Greg, Martin and Doug elaborated
on. Certainly we've got users who would find the removal of that facility a step
backwards. As Doug points out, it adds the possibility of future extensibility
(or implementation specific optimizations) without adversely affecting the
specification.
The correlation id is definitely a hold-over from
earlier versions and is not necessary. Greg, I'll add your issue to
bugzilla.
AssertionWithProtocolURIType also falls into this
category.
Mark.
---- Mark Little, Chief Architect, Arjuna
Technologies Ltd. www.arjuna.com
----- Original Message -----
Sent: Monday, January 17, 2005 5:10
PM
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 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
|