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: Concerns about Switch in April 2004 Specification RE: Sorry - Re: Probable Mistake

The first problem you mentioned is actually not quite there - we didn't
remove "revision marks" from MS Word so part of the text you mentioned
is "struck through" - will fix that in the next draft.

You are right about the second (schema) problem.  Also, all the links
are broken (they take you to the wrong version of the document).  This
may be part of the confusion.  *We need to clean up the draft*. 

Thanks for the comments!


-----Original Message-----
From: andrew.francis@mail.mcgill.ca
Sent: Monday, May 24, 2004 12:03 PM
To: Satish Thatte
Subject: Concerns about Switch in April 2004 Specification RE: Sorry -
Re: Probable Mistake

Hello Satish:

> no problem -- the more eyes verifying the schema the
> better!

Thanks. That said, I have questions about the Switch
activity. It seems that the way conditions are expressed
have changed between the May 2003 and April 2004
specifications. I am having difficulty understandingthe Switch
definition and I believe the definition may have
problems. Perhaps you can clarify things?
Comment One:

In section 6.2 of the  April 2004 specifcation, tSwitch is
defined as:
<switch standard-attributes>
        <condition expressionLanguage="anyURI"?>
          ... bool-expr ... ">+

Why can one or more "condition" elements be present? I would
suspect that only one condition element could appearin a case. Since
Condition is now an element, perhaps a
Condition description should be added to section 9?
Comment Two:

This is how tSwitch is defined in Appendix D:

<complexType name="tSwitch">
        <extension base="bpws:tActivity">
               <element name="case" maxOccurs="unbounded">
                             <element ref="bpws:condition"/>
                          <attribute name="condition"
               <element name="otherwise"

Does the Case element still have a "condition" attribute? Is
so,  this does not seem consistent with the definition
provided in section 6.2. I  suspect the "case" element
retainsa condition attribute as so not to break past implementations.
If my suspicion is correct, shouldn't the element "case"
"use" attribute be "optional" instead of "required":

currently :   <attribute name="condition" 
type="bpws:tBoolean-expr" use="required"/>suggestion: <attribute
type="bpws:tBoolean-expr" use="optional"/>
as not to break a new implementation that uses the condition
element in lieu of the Condition attribute?
Comment Three:

In the schema, the 'case' element is defined as extending
'tActivityContainer' and has a condition element in its
content model. I am confused by the "case" type declaration.Is it
correct to make "case" an extension of
activityContainer? By making "case" an extension and thendefining a
"condition" element in the contentModel, doesn't
this imply that cases are written, by virtue of section 4.2of the XSD
Schema Primer (content models are added
sequentially: base + extension) as:

instead of:


which is more natural and expected and implied by the schema
in section 6.2? Unfortunately, I don't currently have a
validating XML parser handy to see the effect (i.e,I am notsure
<sequence> has the right effect), so I hope this isn't
a false alarm.
Thank you,

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