[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 294.2 - proposal for vote
Extension declarations refer to the language extension itself ( for example
Java ;-)) , whereas imports refer to instances of definitions (for example
purchaseOrder.wsdl). Therefore, IMO the extension and the import discussion
are two different things.
Because of the fact that Chapter 14 states
<<In order to apply extension semantics to a WS-BPEL process, an extension
syntax token, in the form of an element or attribute qualified by the URI
value of a namespace attribute in an <extension> element that is used
outside of an <extension> element, MUST appear in the WS-BPEL process
definition or its directly referenced WSDL <portType> definitions,
<propertyAlias> definitions or <property> definitions.>>
the following situation arises: I have a XPath function with a given NS,
but this NS does not occur as XML element or attribute in the BPEL itself.
Because of this situation we agree that we cannot have an extension
declaration in the sense of chapter 14. Maybe we can consider to draw an
analogy that XPath extension functions of other namespaces are treated like
BPEL extensions declared with mustUnderstand = yes. We might just add a
clarifying sentence to Danny's proposal:
[From]
A WS-BPEL processor MAY make XPath extension functions of other
namespaces available. If a process definition contains XPath
functions of other namespaces, a WS-BPEL Processor that does not
support one or more of these XPath extension functions MUST reject
the process. This requirement MUST be statically enforced.
[To]
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. This requirement MUST be statically enforced.
Cheers
/Simon
--------------------------------------------------
Simon Daniel Moser, M.Eng.
Business Process Solutions Development 1
IBM Boeblingen Laboratory
Schoenaicherstr. 220, 01/086
D - 71032 Boeblingen
Tel.: +49 - 7031 - 164304
IP Telephone Number (ITN): 39204304
email: smoser@de.ibm.com
Rule of thumb #3459835478: when you find yourself typing/copying the same
thing more than twice in a row, redesign or re-implement. No excuse
possible.
Alex Yiu
<alex.yiu@oracle.
com> To
Danny van der Rijn
06/22/2006 10:46 <dannyv@tibco.com>
PM cc
Simon D Moser/Germany/IBM@IBMDE,
Dieter Koenig1/Germany/IBM@IBMDE,
Diane Jordan <drj@us.ibm.com>,
Peter Furniss
<peter.furniss@erebor.co.uk>,
Thomas Schulze/Germany/IBM@IBMDE,
wsbpel@lists.oasis-open.org, Alex
Yiu <alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue - 294.2 -
proposal for vote
Makes sense to me. Simpler and better.
Thanks.
Regards,
Alex Yiu
Danny van der Rijn wrote:
You've now got a sentence in there that I think adds nothing, and is
confusing. I would remove the sentence in brackets, and reword the
2nd to last sentence.
From
--------------------------------
A WS-BPEL processor MAY make XPath extension functions of other
namespaces
available. [They must be understood by a WS-BPEL processor.] If the
WS-BPEL Processor does not support one or more of these XPath
extension namespaces then the process definition MUST be rejected.
This requirement MUST be statically enforced.
--------------------------------
To
--------------------------------
A WS-BPEL processor MAY make XPath extension functions of other
namespaces
available. If a process definition contains XPath functions of other
namespaces, a WS-BPEL Processor that does not support one or more of
these XPath extension functions MUST reject the process. This
requirement MUST be statically enforced.
--------------------------------
Alex Yiu wrote:
Hi Simon,
I understand your intent.
However, the <import> mechanism in the spec has only covered
importing WSDL and XSD. Of course, it may be extended to
importing XPath functions.
But, I would hesitate to do so. Because:
What exactly does the location of XPath function
definition mean in <import>? [I have a feeling that we
are dancing around the elephant again.]
And, for XPath function there should be no option for
mustUnderstand (which needs to be always true).
While I feel comfortable with the second part of your word
smithing: "If a WS-BPEL
Processor does not support one or more of these XPath extension
namespaces then the process definition MUST be rejected. This
requirement MUST be statically enforced."
So, I may I would take your second half of you suggestion for
part (b).
--------------------------------
A WS-BPEL processor MAY make XPath extension functions of other
namespaces
available. They must be understood by a WS-BPEL processor. If
the WS-BPEL Processor does not support one or more of these
XPath extension namespaces then the process definition MUST be
rejected. This requirement MUST be statically enforced.
--------------------------------
I guess the new text is simplier and preceise enough?
Thanks!
Regards,
Alex Yiu
Simon D Moser wrote:
Hi all,
the intention of the sentence "The declaration [editor
todo: add xref here]
does NOT cover those XPath extension functions and XPath
functions of other
namespace must be always understood by WS-BPEL processor"
is totally
unclear. Therefore, we propose to amend [b] in the
following way:
[from]
WS-BPEL processor MAY make XPath extension function of
other namespace
available. The declaration [editor todo: add xref here]
does NOT cover
those XPath extension functions and XPath functions of
other namespace must
be always understood by WS-BPEL processor. If
unrecognized XPath function
is used and if it is detected by static analysis, the
process defintion
MUST be rejected.
[to]
A WS-BPEL processor MAY make XPath extension functions of
other namespaces
available. If XPath extensions functions of other
namespaces are used, then
these namespaces MUST be
declared as WS-BPEL extension namespaces with the
mustUnderstand attribute
set to "yes" (see Section 14. Extension Declarations). If
a WS-BPEL
Processor does not support one or more
of these XPath extension namespaces then the process
definition MUST be
rejected. This requirement MUST be statically enforced.
Cheers
/Simon
--------------------------------------------------
Simon Daniel Moser, M.Eng.
Business Process Solutions Development 1
IBM Boeblingen Laboratory
Schoenaicherstr. 220, 01/086
D - 71032 Boeblingen
Tel.: +49 - 7031 - 164304
IP Telephone Number (ITN): 39204304
email: smoser@de.ibm.com
Rule of thumb #3459835478: when you find yourself
typing/copying the same
thing more than twice in a row, redesign or re-implement.
No excuse
possible.
Danny van der
Rijn
<dannyv@tibco.com
To
> Alex Yiu
<alex.yiu@oracle.com>
cc
06/21/2006 10:28
wsbpel@lists.oasis-open.org, Thomas
PM
Schulze/Germany/IBM@IBMDE, Dieter
Koenig1/Germany/IBM@IBMDE, Diane
Jordan
<drj@us.ibm.com>, Peter
Furniss
<peter.furniss@erebor.co.uk>
Subject
Re: [wsbpel] Issue
- 294.2 -
proposal for vote
For part [b] I would change:
These extensions are defined in the standard WS-BPEL
namespace.
to read:
These extensions are defined in the standard WS-BPEL
*executable*
namespace.
Alex Yiu wrote:
Hi, all,
Here is the formal proposal for vote for issue
294.2: Clarification
namespace usage in Abstract and Executable Process:
======================================
[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
After these 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.
--------------------------
Add clarification text on XPath extension function
for other NS, as
follows:
--------------------------
WS-BPEL processor MAY make XPath extension function
of other
namespace available. The declaration [editor todo:
add xref here]
does NOT cover those XPath extension functions and
XPath functions of
other namespace must be always understood by
WS-BPEL processor. If
unrecognized XPath function is used and if it is
detected by static
analysis, the process defintion MUST be rejected.
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
---------------------------------------------------------------------
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]