[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [wsbpel] WS-BPEL XML Schema - Global Element Declaration or LocalElement Declaration
Resending - used <dk> ... </dk> instead of color coding in my comments to
Alex' note.
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
----- Forwarded by Dieter Koenig1/Germany/IBM on 10.05.2006 18:38 -----
Dieter
Koenig1/Germany/I
BM To
Alex Yiu <alex.yiu@oracle.com>
10.05.2006 14:32 cc
wsbpel@lists.oasis-open.org, Thomas
Schulze/Germany/IBM@IBMDE, Simon D
Moser/Germany/IBM, Ron Ten-Hove
<Ronald.Ten-Hove@Sun.COM>
Subject
Fw: [wsbpel] WS-BPEL XML Schema -
Global Element Declaration or Local
Element Declaration
Hi Alex, it is not yet clear to me why we need a GED "scope" and an
<element ref="bpel:scope"/> when
<element name="scope" type="bpel:tScope"/>
can do the job. Same for many other cases.
All WS-BPEL needs to expose is <bpel:process>, <bpel:service-ref>,
<bpel:property> and <bpel:propertyAlias>; section 5.1. makes it pretty
clear that the only root element in a definition artifact is <bpel:process>
.
"Schema for Schemas" is just one example - WSDL is another (exposing
<definitions> as the only GED).
There should be three XML schema artifacts where each one exposes exactly
what is required:
1. WS-BPEL XML schema for process validation - one GED <bpel:process>
2. WS-BPEL XML schema for property validation - two GEDs <bpel:property>
and <bpel:propertyAlias> (issue 192 did not imply merging them into the
main XSD)
3. WS-BPEL XML schema for process modelers - one GED <bpel:service-ref>
More comments <dk> ... </dk>.
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
Alex Yiu
<alex.yiu@oracle.
com> To
Alex Yiu <alex.yiu@oracle.com>
08.05.2006 23:12 cc
Dieter Koenig1/Germany/IBM@IBMDE,
wsbpel@lists.oasis-open.org, Thomas
Schulze/Germany/IBM@IBMDE, Alex Yiu
<alex.yiu@oracle.com>, Ron Ten-Hove
<Ronald.Ten-Hove@Sun.COM>
Subject
Re: [wsbpel] WS-BPEL XML Schema -
Global Element Declaration or Local
Element Declaration
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>
<dk> , <from>, <to> </dk>
and all activities as global elements, while BPEL 1.1 has only declared
<process>
<dk>, <from> and <to> </dk>
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). No! 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.
<dk>A global complexType is also significant.</dk>
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.
<dk>This would lead us on a strange path. We would also want to
declare several attributes globally if we follow this rationale.</dk>
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.
<dk>Sufficient from a BPEL perspective!</dk>
(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.
<dk>BPEL doesn't need that as long as the type is 100% identical.
</dk>
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.
<dk>I can see no link at all to abstract processes. There is no
normative statement in the spec talking about "fragments".</dk>
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]