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:alex.yiu@oracle.com]
Sent: Thursday, March 11, 2004 6:13 PM
To: Assaf Arkin
Cc: Satish Thatte;
ygoland@bea.com; wsbpeltc; ALEX.YIU@oracle.com
Subject: Re: [wsbpel] Issue 103 -
Good Idea!
Assaf,
I think your simplification is a good idea in general.
However, still some extra data points for you guys to consider .... :-)
(A)
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
.
(B)
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.
[
The semantics is similar to XSLT:
http://www.w3.org/TR/xslt#section-Expressions
"the set of namespace declarations are those in scope on the element which
has the attribute in which the expression occurs;"
I am going to make a proposal to Issue #102 soon. If you don't like this
namespace-prefix inheritance idea. Please let me know.
]
As of now, most of BPEL examples in the spec is using BPEL namespace as the
default namespace.
<assign>
<from expression="$myVar/abc" />
...
</assign>
Using a semantics similar to XSLT the "abc" location Xpath may
point to "abc" element under BPEL namespace?? [ I hope my
understanding is right. :-) ]
<bpel:assign>
<bpel:from expression="$myVar/abc" />
...
</bpel:assign>
If the explicit bpel prefix is used, the prefix-to-NS picture would be more
clear.
Another version that works but kind of ugly:
<assign>
<bpel:from xmlns:bpel="..." xmlns=""
expression="$myVar/abc" />
...
<assign>
Note: xmlns="" is used
to reset the default xmlns.
(C)
Another question that we need to answer is:
The variables declared in BPEL ... do they belong to the targetNamespace?
Or, they are always unqualified?
In short:
(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??
Regards,
Alex Yiu
Assaf Arkin wrote:
Alex,
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:
$tns:myPOMessageVar/pos:customerInfo
However, if the message type is an element, you would want to reference the
element so:
<message name="POMessage">
<part name="customerInfo"
element="sns:customerInfo"/>
<part name="purchaseOrder"
element="sns:purchaseOrder"/>
</message>
$tns:myPOMessageVar/pos:customerInfo/sns:customerInfo
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:
$myPOMessageVar/customerInfo/sns:customerInfo
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.
Assaf
Alex Yiu wrote:
Hi,
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:
<message name="POMessage">
<part name="customerInfo"
type="sns:customerInfo"/>
<part name="purchaseOrder"
type="sns:purchaseOrder"/>
</message>
I guess it may look like this:
$tns:myPOMessageVar/pos:POMessage/pos:customerInfo/sns:customerInfo
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)
Thanks!
Regards,
Alex Yiu
Satish Thatte wrote:
Alex,
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?
Satish
-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Thursday, March
11, 2004 2:25 PM
To: ygoland@bea.com
Cc: wsbpeltc; ALEX.YIU@oracle.com
Subject: Re: [wsbpel] Issue 103 - Good Idea!
Yaron,
Thanks for agreeing with me on Issue 103. :-) Really appreciate it.
And, yes, potentially we can using path segment to deal with WSDL messsage parts
also.
Do you prefer dealing the WSDL message part issue also in Issue 103? Or,
we can separate it in another issu?. The later will allow us to vote on Issue
103 faster.
Thanks again!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
The more I think about 103 the better an idea I think
it is.
I wonder if we couldn't possibly make it work for WSDL types messages?
Could we say that if the variable is of type WSDL
message then there MUST be at least one path segment attached to it and that
the path segment MUST be the name of a part in the WSDL message?
Yaron
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.