Change to TestSuite.xsd

[Daniel Lübke]

Hi,

I want to include the possibliity to add documentation to every activity. I would like to do this on the top-level "Activity" type. Hower, the TwoWayActivity type declares an <xs:all> which essentially prohibits me to add any elements on any super type.
There are two options:
1. Switch the <xs:all> to an <xs:sequence>: This would break backwards-compatibility with existing bpts files if they use a different order than specified in the schema
2. Add the documentation to every element separately: This would increase implementation effort because one would need to cast to the subtype before extracting the data

What is your opinion?

Daniel

[Antonio García Domínguez]

Hi Daniel,

If possible, I'd like to preserve backwards probability with existing .bpts files.

How about switching to <xs:choice maxOccurs="unbounded"> and making sure that there's exactly one send and one receive element in the Java code?

Kind regards,

Antonio

--
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "BPELUnit" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an bpelunit+u...@googlegroups.com.
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.

[Antonio García Domínguez]

Hi again,

Oops, I meant "backwards compatibility". I need my coffee :-D.

Kind regards,

Antonio

[Daniel Lübke]

Hi,

this would make it

<xs:sequence>
                    <xs:choice>
                        <xs:sequence>
                            <xs:element name="receive" type="ReceiveActivity" />
                            <xs:element name="send" type="SendActivity" />
                        </xs:sequence>
                        <xs:sequence>
                            <xs:element name="send" type="SendActivity" />
                            <xs:element name="receive" type="ReceiveActivity" />
                        </xs:sequence>
                    </xs:choice>
                    <xs:element name="mapping" type="Mapping" minOccurs="0" />
                    <xs:element name="headerProcessor" type="HeaderProcessor"
                        minOccurs="0">
                        <xs:annotation>
                            <xs:documentation>Header processor. Can add addressing info to
                                outgoing calls and extract it from incoming calls.
                            </xs:documentation>
                        </xs:annotation>
                    </xs:element>
                </xs:sequence>

mapping and headerprocessor would then be fixed to the end, though, which was different before. This can be generated in XMLBeans just fine and interestingly, it only generates one set and get for receive and send activities.

[Daniel Lübke]

But this still breaks already some test suites in .framework. The <all> is really nasty... :(

[Antonio García Domínguez]

Hi Daniel,

How bad is it? Can you push the change to some new branch, so I can try it out this evening?

Cheers,

Antonio

2014-09-10 12:09 GMT+02:00 Daniel Lübke <daniel...@gmail.com>:

But this still breaks already some test suites in .framework. The <all> is really nasty... :(

--

[Daniel Lübke]

Hi,

it's not bad. It would need six of our bpts in the unit tests to change. I can make this but it returns to the question whether and to what extent this change will be backwards compatible or not...

[Daniel Lübke]

https://github.com/dluebke/BPELUnit/tree/feature-metainformation

I pushed it here. Build fails though

[Antonio García Domínguez]

Hi Daniel,

I've pushed a fix for the tests to bluezio/feature-metainformation. It was simple enough: that bit of XSD asks for send+receive or receive+send followed by 0+ mappings and 0+ headerProcessors. In the test, we had the mappings or the headerProcessors before the send/receive elements, which was wrong according to the new XSD.

Nevertheless, if we wanted to accept the old .bpts files, we'd need to do something like this instead of the big xs:sequence, and check ourselves that we've got exactly one send and one receive element. We can place a minOccurs="2" as we'll have the receive and send elements at least:

<xs:choice maxOccurs="unbounded" minOccurs="2">

<xs:element name="receive" type="ReceiveActivity" />

<xs:element name="send" type="SendActivity" />

<xs:element name="mapping" type="Mapping" />

<xs:element name="headerProcessor" type="HeaderProcessor" />

</xs:sequence>

I haven't tried it yet, though. What do you think?

Cheers,

Antonio

2014-09-10 13:04 GMT+02:00 Daniel Lübke <daniel...@gmail.com>:

https://github.com/dluebke/BPELUnit/tree/feature-metainformation

I pushed it here. Build fails though

--