Re: [ebxml-bp] Report from the V2 Schema Trenches - Good news / Bad news

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

Title: Message

Dale,

 

Actually I managed to resolve these in discussion with Martin as noted.

 

The Colloboration Activity link is a little obtuse - but makes sense

once you step in thru.  It's not really recursive - one for a clear

explanation in the specification...

 

The other on the order of items in BinaryCollaboration - despite the

linkage mechanism - this is very confusing - since as the schema

was it forced you to do all joins, then all forks, then all, etc - and the

intent was *not* that but to try and use the schema to validate if

a TA had a success condition etc.  Clearly the schema cannot do

that - so best to remove the restrictions as they just cause wanton

havoc and make parsing the XML instance and models very difficult.

 

With the latest revision to the schema its more in line with the

original 1.09 and everything is in a natural sequence as you would

expect it to be.

 

Anyway - I believe the latest schema posted by Martin resolves

all this well.

 

Thanks, DW

----- Original Message -----

From: Dale Moberg

To: David RR Webber ; BPSS ebXML

Sent: Tuesday, June 01, 2004 1:34 PM

Subject: RE: [ebxml-bp] Report from the V2 Schema Trenches - Good news / Bad news

I am just beginning to catch up on a lot of last week's mailing list traffic. Comment in-line.

 

[omitted]

 

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.