[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 294 - subissue - 294.2 - Proposal for Discussion -Clarification of normative status of XML Schemas and decisions onpreferred design patterns
Hi Alex,
my example in (3.5) is a little bit outdated ;-) Please ignore it. But lets
replace it with the following:
<bpel:assign>
<bpel:targets>
<bpel:target linkName="MyLink"/>
</bpel:targets>
<bpel:copy>
<bpel:from>
$MyVariable/tns:epr
</bpel:from>
<bpel:to partnerLink="MyPartnerLink"/>
</bpel:copy>
</bpel:assign>
Equal questions rise up
- How are the BPEL-internal references of the link, variable and the
partnerLink resolved? There are no definitions for it. Are they invalid?
- How are other normative statements satisfied that for example say
something about type-compatibility? The type of the variable is not known.
- What is the expression language (there's only a default on bpel:process)?
- What is the value of suppressJoinFailure (there's only a default on
bpel:process, too)?
Adding an <extensibleAssign> into this example or another kind of extension
element/attribute rises an additional question:
- Since extensions can be declared only on process - the added extension,
is it mustUnderstand="yes" or mustUnderstand="no"? The default would be
"no" here. Therefore it would not be possible to use mustUnderstand="yes"
extensions in BPEL fragments? That would be strange...
Bottom line is that supporting BPEL fragments is currently totally
unspecified and would require major changes in the spec. Therefore, IMO
LEDs MUST be used in the schema.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
----- Forwarded by Thomas Schulze/Germany/IBM on 10.06.2006 09:07 -----
Thomas
Schulze/Germany/I
BM To
Alex Yiu <alex.yiu@oracle.com>
09.06.2006 23:59 cc
Alex Yiu <alex.yiu@oracle.com>,
Dieter Koenig1/Germany/IBM@IBMDE,
Diane Jordan <drj@us.ibm.com>,
Peter Furniss
<peter.furniss@erebor.co.uk>,
wsbpel@lists.oasis-open.org
Subject
Re: [wsbpel] Issue - 294 - subissue
- 294.2 - Proposal for Discussion -
Clarification of normative status
of XML Schemas and decisions on
preferred design patterns(Document
link: Thomas Schulze)
Hi Alex,
I have no strong feelings splitting up the issue into two. I agree that the
one might be discussed and approved much more faster than the other.
But I really think we need to open both of them. I think there is no other
issue where the merging of the schemas and the introduction of GEDs have
been discussed and formally approved. In case I've overseen it, can you
please point me to this issue? If there is no issue with which this changes
have been formally approved, I think we either need to discuss and formally
approve a solution with this issue (or a sub-issue) or the merging of the
schemas and the introduction of GEDs must be undone.
That was my reasoning regarding the formal change process, now my technical
reasoning regarding the proposed solution.
(1) Normative status
I agree with you that the schema must be normative, else there is no issue.
If the decision is that the schemas are not normative, IMO it is pretty
clear from the spec text that <process> is the only root element of a valid
BPEL and nothing else is allowed. And it is pretty clear from the spec that
<property> and <propertyAlias> are extensions to WSDL and therefore need to
be GEDs, same for <service-ref>.
(2) One or multiple schemas
I don't agree with you on that point.
(2.1)
IMO splitting up the schema is more user-friendly, because it makes clear
that all three schemas are for three different things. The main schema is
the syntax description for the process definition itself, the property
schema is for BPEL's WSDL extensions (as well as the partnerLinkType
schema) and the service-ref schema is for use as a data type inside a
process. This means the service-ref schema is intended to be a part of
process definitions. Especially for this case it will be much more
user-friendly if there's a separate schema containing only the service-ref
stuff.
Maybe we should think about introducing a separate namespace for <property>
and <propertyAlias> (compare with partnerLinkTypes) and a separate
namespace for <service-ref> to make the difference more clearer, not by
only separating the schemas. But it might be to late for such a change.
(2.2)
When introducing new namespaces, the tns of these two schemas can be used
as location for reference, too (your second point).
(2.3)
Avoiding duplication is done by including/importing the main schema into
the other schemas. So there's really no duplication needed.
(2.4)
It's new to me that splitting up the same tns is no good practice. Everyone
is doing this (too with other artifacts, i.e. WSDL) and XML Schema
explicitly allows that. As described above the different element
definitions are for different purposes and that should be documented by
splitting up the schema.
(2.5)
Another important point here, the decision on that topic highly depends on
the GED/LED discussion. If GED is used there is no additional argument for
splitting up the schemas. But if we decide for LEDs it's obvious that the
schemas need to be splitted up. Only then we really have only one element
in the main schema.
(3) GED vs. LED
I don't agree with you on that point, too.
(3.1)
As you've said above the dotted list, GED is not implied by the spec ;-) So
why do we need it?
(3.2)
Elements are NOT referenced by QName in the spec i.e. the string
<bpel:invoke> is not contained in the spec. We always use 'invoke' or
'<invoke>' in HTML Typewriter font. Too, we often refer attributes the same
way. Following your argumentation we have to introduce Global Attribute
Declarations (GAD), too. But this would make some existing BPELs invalid
because the globally defined attributes then need to be prefixed with i.e.
bpel: if the default ns is not set to BPEL.
Furthermore, the spec does not require that a QName, i.e. <bpel:invoke>, is
unique under it's tns. Furthermore the usage of LEDs underlines that for
example <bpel:scope> used in <onEvent> is different than used as here:
<bpel:process ...>
...
<bpel:flow ...>
...
<scope ...>...</scope>
...
</flow>
</process>
In <onEvent> and <forEach> the spec puts additional requirements on the
child scope, i.e. the variable syntactically 'defined' on <onEvent> is
implicitly defined on the contained scope. This means the usage of the
QName <bpel:scope> has slightly different semantics depending on where it
is used and this can ONLY be expressed by using LEDs.
(3.4)
Intention of a schema. What's the intention of a schema? IMO it's (a) for
documenting for other people in a standardized format the syntax of a data
structure and (b) for schema validation. For both purposes LED is the only
choice. The <process> MUST be the root element of a compliant WS-BPEL
process.
(3.5)
Other specifications and fragments. I have not yet heard any good reason
why other specifications have decided to use GEDs. All I have heard from
other people working on other specifications is "It's up to you."
I think the real question is: Does WS-BPEL allow a kind of stand-alone BPEL
fragments as you have given an example for? I would say, no currently not
(and that's the difference to other specifications). Looking at your very
simple example, already rises the following question: How is the referenced
type foo:bar imported? The spec currently says: "A WS-BPEL process
definition MUST import all XML Schema and WSDL definitions it uses. This
includes all XML Schema type and element definitions...". Is that true for
this fragment? I don't know, it's undefined. Some may say yes and use
bpel:import in the surrounding document to import that type, some may say
no and use an own import mechanism.
Looking at the following fragment example other big questions are not
answered:
<bpel:assign>
<bpel:targets>
<bpel:target linkName="MyLink"/>
</bpel:targets>
<bpel:copy>
<bpel:from variable="MyVariable">
<bpel:query>tns:id</bpel:query>
</bpel:from>
<bpel:to partnerLink="MyPartnerLink"/>
</bpel:copy>
</bpel:assign>
- How are the BPEL-internal references of the link, variable and the
partnerLink resolved? There are no definitions for it. Are they invalid?
- How are other normative statements satisfied that for example say
something about type-compatibility? The type of the variable is not known.
- What is the queryExpression (there's only a default on bpel:process)?
- What is the value of suppressJoinFailure (there's only a default on
bpel:process, too)?
I think using GEDs in the schema and allowing fragments by that, introduces
a lot of new questions which are not answered in the spec until now. That's
an additional reason why we need to open this (sub-) issue and discuss
about it.
I prefer LEDs. Answering all these questions would require massive changes
in the spec because the whole spec is written in the assumption that there
are no fragments allowed.
Dieter mentioned in a previous mail to check the copyrights if an extension
can introduce GEDs when it needs them. Maybe we should discuss this option,
too.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Alex Yiu
<alex.yiu@oracle.
com> To
Alex Yiu <alex.yiu@oracle.com>
05.06.2006 03:35 cc
wsbpel@lists.oasis-open.org, Dieter
Koenig1/Germany/IBM@IBMDE, Peter
Furniss
<peter.furniss@erebor.co.uk>, Diane
Jordan <drj@us.ibm.com>
Subject
Re: [wsbpel] Issue - 294 - subissue
- 294.2 - Proposal for Discussion -
Clarification of normative status
of XML Schemas and decisions on
preferred design patterns
Hi all,
Given this list of discussion items:
-----------------------------------------------
Subject: Issue - 294.2 - Clarification of normative status of XML Schemas
and decisions on preferred design patterns
Description:
Normative Status:
Whether the XML Schema provided this specification is normative
was discussed in a conf call few weeks ago. However, there was
no formal conclusion reached during the conf call. A formal
clarification/decision should be reached before discussing
other topics regarding to schema and grammar enforcement by the
specification.
Another question include: do we allow WS-BPEL implementation to
implement other xml grammar language to enforce the syntax of
this specification?
XML Schema Design Patterns:
One or multiple schema document: For XML syntax of one
particularly target namespace, should we have one XML schema to
cover its definition? Or, we should have a set of disjoint XML
schemas to cover one namespace?
GED-vs-LED: In XML Schema, an element can be in forms of either
Local Element Declaration (LED) or Global Element Declaration
(GED). Which pattern are the preferred one? There are different
pros and cons in this decision.
In BPEL 1.1 main XML schema, there are a number of
elements which are GED: "process", "from" and "to"
-----------------------------------------------
Proposal Draft (so far, subject to further discussion):
Normative status of XML Schema:
Based on what I heard so far, people seem to prefer XML schema being
normative. I would presume that is the direction that we want. However, I
am personally open to make the XML schema non-normative (i.e. an
illustrative example grammar).
Here is the proposed text to add as the preamable of XML Schema Appendix:
-----------------------------------------------
XML Schema listed in this appendix are considered normative parts of the
specification and used to provide further grammar restrictions on WS-BPEL
syntax desribed by the main part of this specification. If XML Schema has
contradictions with the main part of this specification, instead of
restriction, the main part of the specification are considered to be the
source of truth.
This specification does NOT mandate implementation of WS-BPEL processors to
use XML Schema as the only mechanism to perform grammatical checking of
WS-BPEL constructs. Other mechanisms are allowed to be used as long as the
result does not contradict the main part of the specification.
-----------------------------------------------
Past Discussion:
http://www.oasis-open.org/archives/wsbpel/200605/msg00121.html
http://www.oasis-open.org/archives/wsbpel/200605/msg00138.html
http://www.oasis-open.org/archives/wsbpel/200605/msg00146.html
One or multiple schema document per target namespace:
I suggest to have one schema document per target namespace. Because:
It will be more user-friendly (Dieter's point)
Make it feasible to make the target namespace is a de-referenceable
location for people to fetch schema (See opened issue 289)
To avoid duplication of XML Schema(See Issue 192 to make <property>
and <propertyAlias> extensible) and to avoid conflicting as well
(Note: different schemaLocation is like different classloader).
There are no other XML / WS-* (AFAIK) specification would spilt the
schema definition of one target namespace into multiple pieces.
(Spiltting schemas up is not a good practice.)
GED-vs-LED:
This may be the most complicated item for discussion for this issue.
I propose that we should use GED whenever possible in our schema design. I
think that GED is neither useless nor implied by the spec text. Let me
summarize reasons mentioned in some of past discussion here:
Spec Text Implies GED: In our spec text, we usually refer to an
activity or a construct just with its QName (e.g. <bpel:invoke>,
<bpel:assign>, <bpel:eventHandlers>). That essentially means that
QName is globally unique under that targetNamespace. There are NO
more than one definition of <bpel:eventHandlers>. XML Schema should
reflect that intention as much as possible by using GED.
GED != Root Element and Majority of XML and WS* Spec are using GED:
In XML Schema specification, Schema for Schema are using GED as much
as possible, even though <xsd:schema> is the only valid Root Element.
Similarly situation applied to WSDL 2.0 and a bunch of other WS-*
specification. They use GED extensively on non-Root Element. It
really means GED does NOT imply that element is a root element. That
is **the** trend of all well-know specifications. In fact, WSDL 1.1
is using a lot of LED, while WSDL 2.0 transits to use GED. BPEL 1.1
=> BPEL 2.0 should follow a similar transition. If we use LED in BPEL
2.0, that would essentially saying to WSDL 2.0 and XML Schema authors
that they made a wrong decision.
[ Another example XML Schema for XML Syntax for XQuery (XQueryX) ]
BPEL Fragment Support for Execution Completion: When people uses BPEL
fragments to contain the Execution Completion information of Abstract
Process, it would be very beneficial that Execution Completion XML
information can refer to the Elements of BPEL syntax and reuse the
XML schema syntax validation.
e.g.: some psuedo XML info for Execution Completion
-------------------------
<vendorX:executionCompletion insertionPoint="....">
<bpel:variable name="myVar" type="foo:bar" />
</vendorX:executionCompletion>
-------------------------
If <bpel:variable> is a local element only in our schema, then
vendorX will may need to define its own with the targetNamespace
pointing to bpel namespace, in order to do syntax validation. That is
just a bad practice that a namespace owned by an OASIS spec and but a
vendor can define and declare things that namespace. It is similar to
the situation that a vendorX define a new class in the java package
"javax.some-java-standard" owned by the standard.
To make Execution Completion as an implementation reality, we need
BPEL fragment supports in XML Schema in forms of GED.
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 and WSDL 2.0 as
our predecessor example, it should not be a problem, e.g.., an XSD
processor would not accept a schema started with <xsd:documentation>
as their root element.
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
Hi, Dieter,
I am a bit confused.
I thought we would try to cover Action Item #74 by this issue
as well?
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/action_item.php?action_item_id=1434
Also, I suggested to declare formally how normative XML Schema
Artifacts are. Before we go into the GED-vs-LED discussion. If
the XML Schema is informal, there is no point to have a
GED-vs-LED discussion.
The first 3 bullets mentioned in the issue description is
related to the namespace usages, while the fourth is about
schema design. They are orthogonal to each other. One decision
does not affect the other. We should NOT mix these group issues
together. Implementation may use other non-XML-schema to
enforce the grammar specified by the spec text or XML schema.
Also, it seems to me that there would be multiple XML Schema document
for the same Exec-BPEL in the submitter's proposal. I thought I was
able to at least to convince Dieter that one schema document for one
target namespace is a good practice:
See: http://www.oasis-open.org/archives/wsbpel/200605/msg00146.html
Now I am really confused.
Anyhow, I formally suggest to add some of the above concerns to this
issue description and spilt this issue into two sub-issues: one for
namespace usage; one for XML Schema status and design pattern.
[Assume the namespace related issue is numbered as "294.1".]
-----------------------------------------------
Subject: Issue - 294.1 - Clarification namespace usage in Abstract
and Executable Process
Description:
According to the resolution of issue 24, there will be two WS-BPEL
2.0 XML schema artifacts, each with its own target namespace, one for
Executable Processes and one for Abstract Processes.
There are several problems associated with this approach:
1. The XML schema types and elements for Properties and Property
Aliases appear currently in the Executable Process namespace.
It is *unclear* whether they should also be in the Abstract
Process namespace as well. If they are, then it is *unclear*
which one to use in the WSDL.
2. The XML schema types and elements for Service References would
similarly appear in both namespaces - it is *unacceptable* that
the namespace changes when switching between Abstract and
Executable - if this schema type would appear on a WSDL
operation then this switch would cause a change of the
interface.
3. For XPath extension functions defined by WS-BPEL, we again have
the same situation: is is unclear whether both namespaces would
be used to qualify them - again, it is *unacceptable* that the
namespace changes when switching between Abstract and
Executable.
Also, we do not have text to describe how to treat XPath function of
other namespaces. See action item #74
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/action_item.php?action_item_id=1434
-----------------------------------------------
[Note:
(1),(2),(3) are exact copies of Dieter's original issue
description. Green text are added for Action #74.
In general, for (1) to (3), I agree with Dieter's general
direction. Use "bpel" ns, instead of "abstract" ns all the time
in these 3 context. And, I would propose adding text from
Action #74 as well.]
-----------------------------------------------
Subject: Issue - 294.2 - Clarification of normative status of XML
Schemas and decisions on preferred design patterns
Description:
Normative Status:
Whether the XML Schema provided this specification is
normative was discussed in a conf call few weeks ago.
However, there was no formal conclusion reached during
the conf call. A formal clarification/decision should be
reached before discussing other topics regarding to
schema and grammar enforcement by the specification.
Another question include: do we allow WS-BPEL
implementation to implement other xml grammar language to
enforce the syntax of this specification?
XML Schema Design Patterns:
One or multiple schema document: For XML syntax of one
particularly target namespace, should we have one XML
schema to cover its definition? Or, we should have a set
of disjoint XML schemas to cover one namespace?
GED-vs-LED: In XML Schema, an element can be in forms of
either Local Element Declaration (LED) or Global Element
Declaration (GED). Which pattern are the preferred one?
There are different pros and cons in this decision.
In BPEL 1.1 main XML schema, there are a number of
elements which are GED: "process", "from" and "to"
-----------------------------------------------
I will send a seperate email to submit a proposal for the second
subissue.
Thanks!
Regards,
Alex Yiu
ws-bpel issues list editor wrote:
This issue has been added to the wsbpel issue list with a
status of "received". The status will be changed to "open" if a
motion to open the issue is proposed and that motion is
approved by the TC. A motion could also be proposed to close it
without further consideration. Otherwise it will remain as
"received".
The issues list is posted as a Technical Committee document to
the OASIS WSBPEL TC pages on a regular basis. The current
edition, as a TC document, is the most recent version of the
document entitled in the "Issues" folder of the WSBPEL TC
document list - the next posting as a TC document will include
this issue. The list editor's working copy, which will normally
include an issue when it is announced, is available at this
constant URL.
Issue - 294 - Factoring of XML Schema Artifacts
Status: received
Date added: 4 Jun 2006
Date submitted: 02 June 2006
Submitter: Dieter Koenig
Document: WS-BPEL 2.0 XML Schema
Description: According to the resolution of issue 24, there
will be two WS-BPEL 2.0 XML schema artifacts, each with its own
target namespace, one for Executable Processes and one for
Abstract Processes.
There are several problems associated with this approach:
1. The XML schema types and elements for Properties and
Property Aliases appear currently in the Executable
Process namespace. It is *unclear* whether they should
also be in the Abstract Process namespace as well. If
they are, then it is *unclear* which one to use in the
WSDL.
2. The XML schema types and elements for Service References
would similarly appear in both namespaces - it is
*unacceptable* that the namespace changes when switching
between Abstract and Executable - if this schema type
would appear on a WSDL operation then this switch would
cause a change of the interface.
3. For XPath extension functions defined by WS-BPEL, we
again have the same situation: is is unclear whether both
namespaces would be used to qualify them - again, it is
*unacceptable* that the namespace changes when switching
between Abstract and Executable.
4. The XML schema contains many global element definitions
instead of just <process> - it is therefore allowed to
create valid documents that only contain a <property>
element (or a <copy> element, etc.), which is useless and
not mandated by the WS-BPEL 2.0 specification.
Submitter's proposal: [Just one option - subject to discussion]
Refactor the WS-BPEL 2.0 XML schema artifacts into the
following:
a. One WS-BPEL 2.0 XML schema for validation of Executable
Processes - the only allowed root element is
<executable:process>
b. One WS-BPEL 2.0 XML schema for validation of Abstract
Processes - the only allowed root element is
<abstract:process>
c. One WS-BPEL 2.0 WSDL extension XML schema for validation
of Properties and Property Aliases - same target
namespace as (a) - the only allowed root elements are
<bpel:property> and <bpel:propertyAlias>
d. One WS-BPEL 2.0 XML schema for Service Reference variable
declaration in Executable or Abstract Processes - same
target namespace as (a) - the only allowed root element
is <bpel:service-ref>
Notes:
The target namespace values for (a) and (b) are valid
URLs that point to the location of the two artifacts,
respectively.
The location of (c) and (d) is provided in a
<xsd:documentation> element contained in (a) and (b).
The XML schema artifact (c) has an <xsd:include> for the
schema (a) in order to be able to reuse the WS-BPEL
extensibility mechanism.
Changes: 4 Jun 2006 - new issue
To comment on this issue (including whether it should be
accepted), please follow-up to this announcement on the
wsbpel@lists.oasis-open.org list (replying to this message
should automatically send your message to that list), or ensure
the subject line as you send it starts "Issue - 294 -
[anything]" or is a reply to such a message. If you want to
formally propose a resolution to an open issue, please start
the subject line "Issue - 294 - Proposed resolution", without
any Re: or similar.
To add a new issue, see the issues procedures document (but the
address for new issue submission is the sender of this
announcement).
---------------------------------------------------------------------
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]