[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Fw: [wsbpel] WS-BPEL XML Schema - Global Element Declaration or LocalElement Declaration
Hi Alex, I definitely buy the usability aspect of having one schema
location. As <bpel:process>, <bpel:service-ref>, <bpel:property>, and
<bpel:propertyAlias> must be GEDs, this single XSD would declare a document
valid which contains e.g. just one property. We probably have to accept
this.
Other than that, funny documents e.g. just containing a <to> element should
be invalid.
The specification does not talk about any reuse scenarios, so there is no
mandate for anything else. It might be worth checking whether an
implementation is (copyright-wise) allowed to include the BPEL XSD in a
private XSD and add elements needed for some reuse scenario there.
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
Dieter Koenig1/Germany/IBM@IBMDE
11.05.2006 04:23 cc
wsbpel@lists.oasis-open.org, Thomas
Schulze/Germany/IBM@IBMDE, Simon D
Moser/Germany/IBM@IBMDE, Ron
Ten-Hove <Ronald.Ten-Hove@Sun.COM>,
Alex Yiu <alex.yiu@oracle.com>
Subject
Re: Fw: [wsbpel] WS-BPEL XML Schema
- Global Element Declaration or
Local Element Declaration
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]