OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 294 - Factoring of XML Schema Artifacts - splittinginto two sub-issues



Peter,

Thanks! Understood. Hopefully, the new issue description is "friendly" to Dieter.

Regards,
Alex

Peter Furniss wrote:
Since 294 hasn't been accepted yet, I'm leaving it as one for the time being (unless asked otherwise).
 
Peter


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: 05 June 2006 00:15
To: wsbpel@lists.oasis-open.org
Cc: Alex Yiu; 'Dieter Koenig1'; Peter Furniss; Diane Jordan
Subject: Re: [wsbpel] Issue - 294 - Factoring of XML Schema Artifacts - splitting into two sub-issues


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