OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel-spec-edit] Issue 94

I am in general agreement that context sensitive checking doesn’t have to be expressed in schema.  We have a lot of it.  But I am not a schema Guru so I will leave definitive opinions to you, Paco and others who feel authoritative on that front :-)



From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Wednesday, April 07, 2004 1:00 PM
To: wsbpel-spec-edit@lists.oasis-open.org
Cc: Alex Yiu
Subject: [wsbpel-spec-edit] Issue 94


Hi all,

I would like to send this proposal for Issue 94 to this editing subgroup first, before sending it to the main BPEL TC mailing list.

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?
If you guys feel OK about this proposal, I will forward this proposal to the main BPEL TC mailing list.

Alex Yiu

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]