[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! Satish -----Original Message----- From: andrew.francis@mail.mcgill.ca [mailto: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> standard-elements <case>+ <condition expressionLanguage="anyURI"?> ... bool-expr ... ">+ </condition> activity </case> <otherwise>? activity </otherwise> </switch> 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"> <complexContent> <extension base="bpws:tActivity"> <sequence> <element name="case" maxOccurs="unbounded"> <complexType> <complexContent> <extension base="bpws:tActivityContainer"> <sequence> <element ref="bpws:condition"/> </sequence> <attribute name="condition" type="bpws:tBoolean-expr" use="required"/> </extension> </complexContent> </complexType> </element> <element name="otherwise" type="bpws:tActivityContainer" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> 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 name="condition" 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: <case> <activity> <condition> </case> instead of: <case> <condition> <activity> </case> 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, Andrew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]