20040902 schema comments / RNC version

[Paul R Brown <prb@fivesight.com>]

Hi, Prasad / Alex --

> Sept 02, 2004 version of the WS-BPEL main schema.

For any fellow emacs/nxml-mode junkies, I have a version of the schema 
in RNC form; it is here[1] for anyone who wants it.  (There is also a 
version[2] of BPEL4WS 1.1 (March 2003).)  I have (probably) made some 
mistakes with the transcription, but there are some niceties with the 
RNC versions, e.g., enforcement of different from-spec's.

In the course of performing the transcription, I came up with a few 
items/comments; I'll request an advance indulgence for anything that 
constitutes overmuch language-lawyering.

1) I agree with Ian's earlier comments about explicitly stating mixed 
content when present (whether or not the minutiae in the XML schema 
specification(s) require it), since it's clearer to someone (God 
forbid) reading the schema.

2) The use of the xs:anyAttribute extensibility mechanism seems a 
little silly from a practical perspective...  The schema states that 
any attributes outside of xmlns:bpel are permitted, but since the 
attributes in the schema are all unqualified, this doesn't really meet 
the goal of excluding the namespace that the schema addresses.  This 
should really be "any namespace-qualified attribute in a non-default 
namespace other than the xmlns:bpel namespace", but this is not 
possible in XML schema[3].  Nonetheless, it could be specified in the 
documentation for the schema or other annotation.

3) The literal form of the from-spec clashes with the extensibility 
elements.  (Is the schema-legal bpel:documentation element part of the 
assignment?)  A non-extensible bpel:literal child would correct this 
asymmetry and make the literal from-spec more explicit:

   from.literal =
     element bpel:from {
       extensibility,
       element bpel:literal {
         ( text* & OTHER* )
       }
     }

4) Having the tTo type be non-extensible (documentation and ##other 
children) seems asymmetric.  (If I can document a bpel:link, I should 
be able to document a bpel:to...)

5) The bpel:service-ref child of the bpel:from is not technically 
allowed by the literal form of the tFrom type (because the service-ref 
element is in the xmlns:bpel namespace).  This should probably be a 
sixth form of the from-spec and explicitly called-out in the schema.  
In RNC, this would be:

   from.service-ref =
     element bpel:from {
       extensibility,
       element bpel:service-ref {
         attribute reference-scheme { xsd:anyURI },
         OTHER+
       }
     }

6) If I may nitpick, the hyphenated names for bpel:service-ref and 
reference-scheme are at odds with the camelCase names used elsewhere in 
the schema.

7) The schema specifies that bpel:import appears zero or one times; 
this should be zero or more.  (The default value[4] of maxOccurs is 1, 
so it should be specified to be "unbounded" in this case.)  Parallel 
construction with other items (variables, events/alarms, 
catch/catchAll, etc.) would suggestion that it be wrapped in a 
bpel:imports element.

8) It is possible to express the grammar for (for|until)?repeatEvery in 
XML schema without introducing non-determinism, so I'll propose the 
following alternative to what's in the schema:

   <complexType name="tOnAlarm">
     <complexContent>
       <extension base="bpws:tExtensibleElements">
         <sequence>
           <choice>
             <element name="for" type="bpws:tDuration-expr"/>
             <element name="until" type="bpws:tDeadline-expr"/>
           </choice>
           <element name="repeatEvery" type="bpws:tDuration-expr" 
minOccurs="0"/>
           <group ref="bpws:activity"/>
         </sequence>
       </extension>
     </complexContent>
   </complexType>

The same holds for the bpel:wait activity:

   <complexType name="tWait">
     <complexContent>
       <extension base="bpws:tActivity">
         <choice>
           <element name="for" type="bpws:tDuration-expr"/>
           <element name="until" type="bpws:tDeadline-expr"/>
         </choice>
       </extension>
     </complexContent>
   </complexType>

9) I'll propose a change to the grammar for tEventHandlers that is 
((bpel:onEvent+ bpel:onAlarm*)|bpel:onAlarm+) instead of (bpel:onEvent* 
bpel:onAlarm*):

   <complexType name="tEventHandlers">
     <complexContent>
       <extension base="bpws:tExtensibleElements">
         <choice>
           <sequence>
             <element name="onEvent" type="bpws:tOnMessage" 
minOccurs="1" maxOccurs="unbounded"/>
             <element name="onAlarm" type="bpws:tOnAlarm" minOccurs="0" 
maxOccurs="unbounded"/>
           </sequence>
           <element name="onAlarm" type="bpws:tOnAlarm" minOccurs="1" 
maxOccurs="unbounded"/>
         </choice>
       </extension>
     </complexContent>
   </complexType>

10) IMHO, it doesn't make much sense to me to have multiple 
bpel:documentation elements head-to-tail at the start, so maxOccurs="1" 
makes more sense.

11) Either no bpel:faultHandlers element on bpel:process and bpel:scope 
or a bpel:faultHandlers child of bpel:invoke would be parallel 
construction.

12) The definition of the importedURI seems overly restrictive, as the 
two values are not the only two legal values.

13) Allowing the use of <xs:any processContents="lax" /> within 
bpel:documentation allows a bpel:documentation element to comment out 
portions of a process, but that's the only reason that I can think of 
to use <any processContents="lax" /> insetad of <any 
namespace="##other" processContents="lax" />

If it's useful, I'm willing to make these edits to the schema and 
circulate it.

	-- Paul

[1] http://blogs.fivesight.com/pbblog/wp-content/bpel_20040902.rnc
[2] http://blogs.fivesight.com/pbblog/wp-content/bpel_1_1.rnc
[3] http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#declare-openness
[4] http://www.w3.org/TR/xmlschema-0/#OccurrenceConstraints