Hi Dieter,
Thank you for your reply.
Assume the schema are normative in this spec. Otherwise, the schema
just became an illustration and we did not want to spend so much time
in this discussion.
Another thing that I guess that we both agree on: this TC should make a
conscious decision on how to use GED and LED in WS-BPEL schema.
[a] Other standards and specifications:
Dieter wrote:
"Schema for Schemas" is just one example - WSDL is another (exposing <definitions> as the only GED).
Actually, you are refering to the schema design of WSDL 1.1.
When you look at other specifications, GED are used extensively.
(including WSDL 2.0)
WSDL 2.0:
http://www.w3.org/TR/wsdl20/
http://www.w3.org/2006/03/wsdl/wsdl20.xsd
[Note: In WSDL 2.0, <description>, <import>,
<include>, <types> all are GED.
LED are used only when same element are associated with two different
types locally. e.g.:
<xs:element name="operation" type="wsdl:InterfaceOperationType"/>
<xs:element name="operation" type="wsdl:BindingOperationType"/>
Obviously, WSDL 2.0 people has adopted the same GED usage pattern as in
XSD Schema for Schema. ]
WS-Addressing 1.0:
http://www.w3.org/TR/ws-addr-core/
http://www.w3.org/2006/03/addressing/ws-addr.xsd
(Note: both WSDL 2.0 and WS-Addressing are already in W3C Candidate
Receommendation Stage)
WS-Policy: (a W3C Submission)
http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/
http://schemas.xmlsoap.org/ws/2004/09/policy/ws-policy.xsd
<xsd:element ref="..." /> usage to refer to a GED in WS related
spec goes on and on ... I don't want to list them all here.
[b] Schema File Structure:
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>
Sorry .... I would need to disagree with you suggestion again.
It is just a bad schema practice to spilt the schema of same target
namespace into multiple files without any <xsd:include> to tie
them up back together. This statement is particularly especially true,
as
<bpel:service-ref> can be used directly within a BPEL process
definition. Further elaboration of reasoning:
(1)
Whenever we use XML schema to validate an XML document, we always
implicitly or explicity associate the document with a particular copy
of XML Schema. When it is done explicitly, it is done with:
xsi:schemaLocation="your-namespace-uri your-schema-location-uri"
One namespace can be only associated with one schema definition. If we
spilt the schema definition of the same namespace into multiple schema,
that means we cannot associated the XML (elements/attributes) of that
namespace with all the related schema definitions. That is, we cannot
validate all XML of that namespace. That is, we cannot validate
<bpel:service-ref> usage with <bpel:process> for example.
(2)
For issue 192, one more reason to merge XSD is to reuse the definition
of "tExtensibleElements". IMHO, we should NOT duplicate the definition
of "tExtensibleElements" in two XSD files.
It brings us into another point. If both a.xsd and b.xsd define
"bpel:tExtensibleElements", they are NOT considered the same type. If
there is c.xsd trying to <xsd:include> both a.xsd and b.xsd, that
the c.xsd will be STILL considered ILLEGAL schema definition.
It is analogous to Java classloader infrastructure, even if the same
class definition is duplicated in two jar files and they are loaded by
two different classloaders, they are considered different classes.
[c] Process Fragments and Abstract Process
<dk>BPEL doesn't need that as long as the type is 100% identical.</dk>
...
<dk>I can see no link at all to abstract processes. There is no normative statement in the spec talking about "fragments".</dk>
...
IMHO, executable completion happens as follow:
A.P. + Process Fragments => E.P.
Pragmatically, those process fragments need to exist independently from
the A.P. and E.P. Because we want to enable the changing of A.P.
without changing the fragments or vice versa. And, E.P. in this case
would be a generated entity.
In the spec now, we have not mentioned explicitly a WS-BPEL
implementation/user can reuse the same type defined in BPEL schema and
declare a new "bpel:scope" element as a GED in the SAME BPEL
namespace. e.g.:
<xsd:element name="scope" type="bpel:tScope" />
So far, I have not seen that kind of practice before. Usually people
would just refer to the GED directly, if the GED is defined. Or, people
would just refer to the global type and declare an element in their own
namespace. E.g. WS-Coordination defines an element of its own namespace
as follow:
<xsd:element name="RegistrationService"
type="wsa:EndpointReferenceType"/>
Generally speaking the BPEL namespace should be owned by BPEL spec.
Other people outside the spec should NOT define new elements in that
namespace.
Unless a normative statement is made to allow WS-BPEL namespace to be
used as the targetNamespace of a schema outside of the specification. A
BPEL fragment cannot exist independently in a namespace owned by
WS-BPEL.
Even if we made such a normative statement, I would still prefer GED.
Much easier and cleaner.
[d] Global Attribute
<dk>This would lead us on a strange path. We would also want to declare several attributes globally if we follow this rationale.</dk>
Indeed, if we really had a global qualified attribute (e.g.
"bpel:someAttr") with global significance, an XSD global attribute
would be defined. But, all of our attributes are just attribute
without any qualified namespace and we have not stressed on their
global signficance so far. On the other hand, ws-policy does have some
its own global declared attributes.
In summary:
- I think we should adopt the same GED-oriented pattern that other
WS* spec and XSD spec have been using and we should reflect the global
significance of WS-BPEL constructs in both spec text and XSD. (Unless
we want to say to other WS* spec, your XSD design is sub-optimal.)
- "bpel:process", "bpel:property", "bpel:propertyAlias" and
"bpel:service-ref" should be defined in the same XSD to allow resuse of
schema definition and to avoid complication of multiple schema
locations.
- Reasons against usage GED seem to be very implementation driven.
That is, removal of one easy step in BPEL source code validator.
Thanks!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
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
---------------------------------------------------------------------
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
|