That's the good news!
Now the issues / questions.
#1 - the schema appears to be recursive - in
a bad way - around
<CollaborationActivity>
which is a child of <BinaryCollaboration>,
and has two
<Performs> required - that reference
<BinaryCollaboration>.
I'm not sure
what the intent was here - but this does not look right!
- suggested fix -
deprecate <CollaborationActivity> as I think
<MultiPartyCollaboration> and
its <Performs> can do what is needed
here.
Dale>
CollaborationActivity does reference a BinaryCollaboration. That allows a
BinaryCollaboration to be reused within a
BinaryCollaboration.
That is not
something new. Is your question whether we should add a well-formedness
rule that states that the nameId referenced MUST not be to the
BinaryCollaboration including the CollaborationActivity element?
#2 - Next I do not think the model for
<BinaryCollaboration> itself in the XSD
is what
it is intended to be.
Specifically
the following sequence is what I believe is what should
be
allowed. I've indented things to make it clearer and omitted
child
stuff to make
it easy to see the flow:
<BinaryCollaboration>
<Role/>
<Start/>
<BusinessTransactionActivity/>
<Success/>
<Success/>
<Failure/>
<Failure/>
<Join/>
<BusinessTransactionActivity/>
<Success/>
<Success/>
<Failure/>
<Fork>
<BusinessTransactionActivity/>
<BusinessTransactionActivity/>
</Fork>
</BinaryCollaboration>
Dale> The
Success and Failure elements (in later schema versions) have a FromLink
that ties to a BTA. The FromLink has an attibute conditionGuard that tells you
what status is needed to actually take the path. I am not sure why the
grouping under BTA is needed. If the FromLink were missing, I could see that
it would be useful.
The schema almost allows this - but does
not!
We could adjust it to do this. Obviously
this is urgent,
as right now - I would say our schema is broken
in that it cannot express logical flows in this
way!
Thanks, DW.