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!


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


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr:;;1900 S. Norfolk St #900;San Mateo;CA;94403;USA
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:650 577 4700
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard



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