Hi, Ugo,
Great ... we are on the same page.
Yes, section 6.2 already included "compensate". I shall add a note that
to state compensate can only be used within FaultHandler and
CompensateHander, when I take the editor pen.
I will add a similar annotation / documentation to the XML Schema
itself.
Regards,
Alex Yiu
Ugo Corda wrote:
Message
Hi
Alex,
I
agree that in this case expressing the proper constraints using Schema
only would result in a very cumbersome schema specification, so it's
fine with me if we add "compensate" to the "activity" group (this is
already informally done in section 6.2, page 26 of the original spec,
where it says "The token activity can be any of the following:" and
includes <compensate> in that list).
The additional contextual
constraints should, of course, be explicitly called out in Appendix D
to make sure that readers understand that the given Schema is not
sufficient for complete validation.
Ugo
Hi all,
Issue - 94 - Proposal to vote
Some background from Issue 95:
(You can skip this part, if you don't care too much about the usage of
schema validation)
A <rethrow /> activity element is introduced for Issue 95
(Rethrow a fault). In theory, we can use schema validation to make sure
rethrow happens only within a fault handler. However, since XMLSchema
version 1.* is mainly context free grammar like (as opposed to context
sensitive), we may need to duplicate a lot of XML definition (e.g.
"activity" vs "activityOrRethrow"; "tSequence" and
"tSequenceWithRethrow" and etc), in order to achieve this constraint in
schema validation. This kind of overhead may be too much for such a
minor syntax differentiation. Therefore, an easier route is taken by
just adding "rethrow" to group "activity" and using implied semantics
of the text of the main spec doc to carry out the post-schema
validation
Therefore, I suggest to take a similar route for Issue 94
Future version of XML Schema (2.0?) may allow us to add "co-constraint"
to specify this kind of contraints more effectively.
Proposal to fix issue 94:
(1) Adding compensate to group "activity"
(2) merge tActivityContainer and tActivityOrCompensateContainer
by replacing all tActivityOrCompensateContainer with
tActivityContainer
[That means: all tActivityContainer now allows compensate
activity.
We should specify in the text in our spec that compensate
activity is allowed only
within a compensation handler]
What do you guys think?
Thanks!
Regards,
Alex Yiu
|