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!


Ugo Corda wrote:

>Assaf,
>
>I think your element-based example should be:
>
> $tns:myPOMessageVar/sns:customerInfo
>
>for consistency with our resolution for Issue 39.
>
>Also, shouldn't the path start with a "/" to indicate an absolute path?
>  
>
The / is only required when accessing nodes from the current context, 
but not when accessing nodes from a variable.

I still don't understand why we need a namespace for the variable name, 
do you expect to have variables from other namespaces? I mean, all 
variables declared in the scope have local names, so why do we need a 
namespace when accessing them?

Assaf


>Ugo
>
>  
>
>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com] 
>>Sent: Thursday, March 11, 2004 5:12 PM
>>To: Alex Yiu
>>Cc: Satish Thatte; ygoland@bea.com; wsbpeltc
>>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_work
>  
>
>>>gr
>>>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_work
>>>gr
>>>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_work
>>>group.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]