|
Hi Tony. A quick answer to your "what would we be
losing": as Doug and others pointed out in the last telecon. what we'd be losing
would be bridging capabilities - the ability for an endpoint to say it's
interested in all AssertionType messages and to deal with them in a backend
manner. It's not as weakly typed as dealing with any SOAP message. Now, one
thing I did wonder about is whether AssertionType in Context is useful;
certainly from our experience we've only been using it within
WS-CF/WS-TXM.
Mark.
----- Original Message -----
Sent: Wednesday, January 26, 2005 10:01
PM
Subject: RE: [ws-caf] minutes rough
draft
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
|