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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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:
- One WS-BPEL 2.0 XML schema for validation of Executable
Processes - the only allowed root element is <executable:process>
- One WS-BPEL 2.0 XML schema for validation of Abstract
Processes
- the only allowed root element is <abstract:process>
- 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>
- 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
|