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.
|