Report from the V2 Schema Trenches - Good news / Bad news

["David RR Webber" <david@drrw.info>]

OK - having resolved the XML instance issues I encountered - I'm now

past all those syntax errors - but now we come to some

fundamental issues in the structure itself.

 

I've reverted to using the version that Dale posted - as it has some

refinements on Martin's - so I consider Dales' as the "latest draft"

here.

 

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.

 

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

 

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.