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


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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

Subject: Re: [wsbpel] WS-BPEL XML Schema - Global Element Declaration or LocalElement Declaration


Alex Yiu wrote:

Hi Dieter and Thomas,
(cc'ing Ron as well; I tend to think he would give some good input here as well)

The email from you guys poses a very interesting question. That is when Global Element Declaration (GED) and Local Element Declaration (LED) should be used in a schema design.
Besides <process>, our BPEL 2.0 schema currently declares <documentation>,  <copy> and all activities as global elements, while BPEL 1.1 has only declared <process> as global.

One interesting thing worths pointing out is: the way that we declare (GED) and define <documentation> is virtually a carbon copy of <xsd:documentation>, which leads me to dive into Appendix A "Schema for Schema (Normative)".


After more thinking and reading, I would actually suggest to adopt GED in BPEL 2.0 schema more comprehensively (i.e. use GED over LED whenever possible). Reasons are listed below:
  • Patterns borrowed from Schema for Schema: In XSD, only <xsd:schema> is the top level element.  However, if one looks into the "Schema for Schema" appendix, they basically use GED whenever they can. Searching for <xs:element ref="..." ... /> will yield their usage. E.g. <xsd:documentation> is not a top level element. But, they use declare it as a global element instead of LED. IMHO, the design is made that way because:

    • The XSD specification wants to stress the global significance of <xsd:documentation>. That is: there is only one definition of <xsd:documentation>, which is significant to whole XSD namespace. LED is used in schema for schema, only when the same element name has two or more very different definitions (e.g. <xsd:simpleType> are "overloaded" with two types "xs:localSimpleType" and "xs:topLevelSimpleType".)
And, in our specification, we usually refer to our element-based construct as simply by its QName (e.g. <bpel:scope> or <bpel:receive>) without any further qualification. That really means we do rely on its global significance. Given the QName of "bpel:scope", there is only one syntax definition (unlike <xsd:simpleType>). Hence, our XSD should reflect this global significance as well.

Also note that: two local element declarations (e.g. <xsd:documentation>) (even based on the same type) are not considered 100% identical from XSD perspective. (Only their type are considered identical). (Similar consideration applies to <scope> within <forEach> and <onEvent> and general occurances of <scope>.) If we use GED, those elements are truely 100% identical.
  • BPEL fragment support: Having GED enabled in schema will allow us to perform syntax validate a BPEL fragment by itself. It is particularly useful for abstract process. One can two or more artifacts (files): (1) abstract process (2) a fragment of BPEL definition (e.g. an activity) to fill in missing parts in abstract process. Syntactic analysis can be achieved easier, if we use GED more comprehensively. e.g.:. an activity can be validated with XSD by itself.

  • The only reason against using more than one GED in a schema design is: before / after the schema validation, a WS-BPEL processor needs to verify whether the root element is <bpel:process>. That is a super easy step to do. Given the schema for schema design as our predecessor example, it should not be a problem, i.e., an XSD processor would not accept a schema started with <xsd:documentation> as their root element.

Let's discuss this topic a bit more and make a conscious decision on this topic and then apply GED/LED comprehensively to our schema.
Further thoughts?

Alex Yiu

Alex Yiu wrote:


Google translates from:
"Änderungen an den BPEL TC XSDs"
"Changes to the BPEL TC XSDs"

I guess Dieter's "translation" does not have the "lost in translation" situation Instead, we have "addition in translation" situation. ... ;-)

[ That is the informal reply to this thread ... :-) ... I will send out a formal reply later ]

Alex Yiu

Dieter Koenig1 wrote:
Resending with a more "readable" subject line :-)
----- Forwarded by Dieter Koenig1/Germany/IBM on 05.05.2006 07:25 -----
             BM@IBMDE                                                   To 
             05.05.2006 07:21                                           cc 
                                       wsbpel@lists.oasis-open.org, Thomas 
                                       [wsbpel] Fw:  Änderungen an den     
                                       BPEL TC XSDs                        

Hi Alex, as discussed in the TC, the current WS-BPEL XML Schema allows
creating valid XML documents that contain root elements other than

For example (I dropped the namespace declarations for readability):
   <copy ...>
is a valid WS-BPEL document !!!

It is only necessary to allow <bpel:process> or <bpel:service-ref> as
WS-BPEL root documents, and <bpel:property> and <bpel:propertyAlias> as
WSDL extension elements.

Thomas created a WS-BPEL XML Schema (with about 15 minor modifications
marked THS) that would avoid valid root documents like the one shown above.
   (See attached file: wsbpel_main.xsd)
Please have a look at it. Thanks in advance!!

Kind Regards

 Dieter König                                Mail: dieterkoenig@de.ibm.com
IBM Deutschland Entwicklung GmbH

 Senior Technical Staff Member               Tel (office): (+49)
7031-16-3426      Schönaicher Strasse 220

 Architect, Business Process Choreographer   Fax (office): (+49)
7031-16-4890      71032 Böblingen

 Member, Technical Expert Council            Tel (home office): (+49)
7032-201464  Germany

(See attached file: wsbpel_main.xsd)
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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