Hi,
I have used the same procedure for allowing
MessagingCharacteristics and BusinessTransactionCharacteristics to be referred to
and to be placed as children of a CPP or CPA root element. BusinessTransactionCharacteristics
may need an extensible model to handle TimeToPerform, and so support for that
has been added (and will eventually be tested.)
So here is a view of the changes (the CPAType is basically
the same):
For MessagingCharacteristics, we would then have
and the type information
To summarize this (and omit the extensibility apparatus
detail), the main additions are to the attribute groups, messagingAttributes
and businessTransactionAttributes. Each of these groups gets an @id and @idRef
attribute of type xsd:ID and xsd:IDREF, respectively. The modeler can then omit
all the attributes except @idRef and thereby refer to a child of the root
element (either CPP or CPA).
I will investigate putting these alternatives into a choice
construct to see if the flavors of MessagingCharacteristics and
BusinessTransactionCharacteristics can be made more modular. I have checked the
schema changes against the main examples used to illustrate the schema usage,
and 2.0 instances can be updated to 3.0 instances by changing the namespace
(and removing the cppa namespace prefix on attributes, if present).
I am attaching a zipfile snapshot of the examples and the
3.0 schema.
Remember that several more changes need to be made (such as
ebMS 3.0 support and ws-policy inclusion) and all the 3.0 annotations need to
be added. However, the schema has moved quite a ways from 2.0 versions, and you
might wish to comment on it in even an incomplete state.
Once the schema seems stable for the current enhancements,
the document will need updates accordingly.