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 103 - Good Idea!


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.

 

 

 

 



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