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)".
http://www.w3.org/TR/xmlschema-1/#normative-schemaSchema
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?
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
Hi,
Google translates from:
"Änderungen an den BPEL TC XSDs"
to:
"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 ]
Regards,
Alex Yiu
Dieter Koenig1 wrote:
Resending with a more "readable" subject line :-)
----- Forwarded by Dieter Koenig1/Germany/IBM on 05.05.2006 07:25 -----
Dieter
Koenig1/Germany/I
BM@IBMDE To
alex.yiu@oracle.com
05.05.2006 07:21 cc
wsbpel@lists.oasis-open.org, Thomas
Schulze/Germany/IBM@IBMDE
Subject
[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
<process>.
For example (I dropped the namespace declarations for readability):
<copy ...>
<from/>
<to/>
</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
DK
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
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
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
|