To: "Alex Yiu" <email@example.com>,"Assaf Arkin" <firstname.lastname@example.org>
Date: Thu, 11 Mar 2004 18:11:37 -0800
I hate to even imagine that we will have a
BPEL process ever refer to a variable of another process. Variables are very
private to each process and should stay that way.
From: Alex Yiu [mailto:email@example.com]
Sent: Thursday, March 11, 2004 To: Assaf Arkin Cc: Satish Thatte;
firstname.lastname@example.org; wsbpeltc; ALEX.YIU@oracle.com Subject: Re: [wsbpel] Issue 103 -
I think your simplification is a good idea in general.
However, still some extra data points for you guys to consider .... :-)
I think using a node-set / sequence is a great idea. :-) It would
simplify the picture without introducing the root element.
However, do we want to make the XPath more similar / forward compatible to WSDL
2.0? Using a schema type as the message type without using message part? If we
make it more similar to WSDL 2.0, it may not be a bad idea to have root element
I am for using unqualified variable/element names in general. Just a little bit
precaution ... To beginning XML tech-stack users, it would be little bit
confusing, when default XMLNS and unqualified element used together.
I am expecting Issue 102 to clarify the XPath used in query/expression will inherit XMLNS-to-prefix mapping from
the hosting element.
If the explicit bpel prefix is used, the prefix-to-NS picture would be more
Another version that works but kind of ugly:
<bpel:from xmlns:bpel="..." xmlns=""
Note: xmlns="" is used
to reset the default xmlns.
Another question that we need to answer is:
The variables declared in BPEL ... do they belong to the targetNamespace?
Or, they are always unqualified?
(A) I am kind of neutral about whether to use root element.
(B) I am for using unqualified element name for simplification, given we change
all of BPEL examples to use non-default namespace
(C) I tend to believe that we should use qualified variable name. Because, we
may want to add the capabilty for one BPEL process to refer to another variable
of another BPEL process. I only have a tendency now, not strong feeling for
this part (c).
More ideas and thoughts from you guys??
Assaf Arkin wrote:
An XPath variable can be a node-set (1.0) or a sequence (2.0), so there's no
need for root element of the message to support multiple message parts. And if
we define the message part as an element (in infoset terms) that encapsulates
the message content (one or more nodes) then there's no need for the type name.
So the expression may be as simple as:
However, if the message type is an element, you would want to reference the
will return the sns:customerInfo element from the customerInfo message type.
It's also possible to further simplify the XPath expression by not using any
namespaces (unqualified variable/element names), so:
This will not lead to any confusion since there can be only one variable called
myPOMessageVar in the scope and only one message part called customerInfo.
Alex Yiu wrote:
I originally introduced the syntax as an addition, because I did not want to
rock the boat too much. If the community really likes this idea, I am up for
replacementment also. That would imply we may want to use Xpath to address the
WSDL 1.1 message part issue also.
Regarding to XPath pointing to WSDL 1.1 message part situation,
Based on the "POMessage" in the first example listed in BPEL spec:
Please pay attention to the prefix and namespace association.
xmlns:tns = BPEL's targetNamespace (can be omitted in some cases)
xmlns:pos = WSDL's targetNamespace
$tns:myPOMessageVar => QNAME to variable
pos:POMessage => root element of that message
pos:customer => part name
sns:customerInfo => QName of XSD Type used in the message part definition
(if complex type is used)
Hmm ... the XPath may look more complicated than most people expect ...??
(if we want stick with true spirit of WSDL 1.1 and XSD)
Satish Thatte wrote:
Are you proposing this as an addition or a replacement for the current
syntax? Sounds like an addition to me from the issue description but is
there a reason to have two syntactic mechanisms?