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.2 - proposal for vote



Hi all,

The amended proposal was passed in today's conf call.
An amendment is made for part (a). The changes is highlighted by "**".
-----------------------------
The Abstract Process namespace URI does not apply to **<partnerLinkType>**, <property>, <propertyAlias> and <service-ref> elements. That means, these elements are not declared in the Abstract Process namespace and MUST be always identified with **their own namespace URIs**, even when used in the context of Abstract Processes.

Similarly, any XPath function defined by this specification are always identified with Executable Process namespace URI, even when they are used in an expression in an Abstract Process.
-----------------------------


Thanks!


Regards,
Alex Yiu


Alex Yiu wrote:

Hi all,

Assuming the TC are OK with the choice of having 4 separating namespaces: abstract, executable, "property+properytAlias", "service-ref" [Dieter indicated that is his preference in issue 294.1]. Here is the slightly revised proposal. (highlighted in blue)

======================================
[a]
At the end of  Section: "13.1.1. URI",
--------------------------------------

The Abstract Process syntax is denoted under the following namespace:

urn:oasis:names:tc:wsbpel:2.0:process:abstract

--------------------------------------
add:
--------------------------------------
The Abstract Process namespace URI does not apply to <property>, <propertyAlias> and <service-ref> elements. These elements are declared in their own namespaces [TODO: add xref to "2. Notational Conventions"], instead of Abstract or Executable Process namespaces. They MUST be always identified with their correseponding, even when used in the context of Abstract Processes.

Any XPath function defined by this specification are always identified with Executable Process namespace URI, even when they are used in an expression in an Abstract Process.
--------------------------------------

[b]
Also formally incorporated the text suggested in action item #74:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/action_item.php?action_item_id=1434

In the paragraph:
--------------------------
The following XPath extension functions are defined by WS-BPEL and MUST be supported by a WS-BPEL implementation:
· getVariableProperty, described below
· doXslTransform, described in section 8.4. Assignment
These extensions are defined in the standard WS-BPEL namespace.
--------------------------

Change the last sentence to:
--------------------------
These extensions are defined in the standard WS-BPEL Executable Process namespace.
--------------------------

Then, add clarification text on XPath extension function for other NS, as follows:
--------------------------
A WS-BPEL processor MAY make XPath extension functions of other namespaces available. If a process definition contains XPath functions of other namespaces, they are treated like WS-BPEL extensions declared with mustUnderstand="yes" (see Section 14. Extension Declarations). Therefore, a WS-BPEL Processor that does not support one or more of these XPath extension functions MUST reject the process definition. This requirement MUST be statically enforced.

Also, the XPath extension functions, as always required by XPath semantics, MUST not perform any side-effect operations visible to the WS-BPEL process.
--------------------------
======================================


Thanks!


Regards,
Alex Yiu



Alex Yiu wrote:

Hi, all,

Here is the revised proposal for vote for issue 294.2:  Clarification namespace usage in Abstract and Executable Process:
(after factoring in suggestion from Danny and Simon)

======================================
[a]
At the end of  Section: "13.1.1. URI",
--------------------------------------

The Abstract Process syntax is denoted under the following namespace:

urn:oasis:names:tc:wsbpel:2.0:process:abstract

--------------------------------------
add:
--------------------------------------
The Abstract Process namespace URI does not apply to <property>, <propertyAlias> and <service-ref> elements. That means, these elements are not declared in the Abstract Process namespace and MUST be always identified with Executable Process namespace URI, even when used in the context of Abstract Processes.

Similarly, any XPath function defined by this specification are always identified with Executable Process namespace URI, even when they are used in an expression in an Abstract Process.
--------------------------------------

[b]
Also formally incorporated the text suggested in action item #74:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/action_item.php?action_item_id=1434

In the paragraph:
--------------------------
The following XPath extension functions are defined by WS-BPEL and MUST be supported by a WS-BPEL implementation:
· getVariableProperty, described below
· doXslTransform, described in section 8.4. Assignment
These extensions are defined in the standard WS-BPEL namespace.
--------------------------

Change the last sentence to:
--------------------------
These extensions are defined in the standard WS-BPEL Executable Process namespace.
--------------------------

Then, add clarification text on XPath extension function for other NS, as follows:
--------------------------
A WS-BPEL processor MAY make XPath extension functions of other namespaces available. If a process definition contains XPath functions of other namespaces, they are treated like WS-BPEL extensions declared with mustUnderstand="yes" (see Section 14. Extension Declarations). Therefore, a WS-BPEL Processor that does not support one or more of these XPath extension functions MUST reject the process definition. This requirement MUST be statically enforced.

Also, the XPath extension functions, as always required by XPath semantics, MUST not perform any side-effect operations visible to the WS-BPEL process.
--------------------------
======================================


Thanks!


Regards,
Alex Yiu







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