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 Yiu wrote:

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

I'm not up on the latest draft of WSDL 2.0, but the last time I checked 
the suggestion was to use sequences, the same way a SOAP message 
contains multiple body parts under the <body> element. You simply ignore 
that element (always the same name) and represent the entire message as 
a sequence of elements. This will work the same way for WSDL 1.1 (but 
adding elements to represent message parts) and WSDL 2.0.

Are they still using complexTypes that are sequences of elements to 
define message types?


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

There's another option to what you listed below. The element name is 
unqualified, but the element can only be contained in a parent element 
that is qualified. Because the element is declared as part of a parent 
element it's not globally accessible, so it doesn't need a prefix. So 
you'll write something like:

<wsdl:definition>
  <operation> ... </operation>
  <bpel:process>
     <receive> ... </receive>
  </bpel:process>
</wsdl:definition>

You don't need a namespace for receive since receive is declared under 
process, there's no confusion with any other globally defined receive 
element.

> (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?

A variable is only accessible from the scope in which it's declared, so 
there's no benefit in adding namespaces. You can't access a variable 
defined in one process with namespace ns1 from another process with 
namespace ns2. So local names work just as well. Since the variable is 
declared only with a local name, I don't see a problem with the variable 
using a local name as well.

The only place where it would make a difference is for properties which 
can be defined in various namespaces. So you if you're accessing a 
property of a message, the variable name could be unqualified, but the 
property name must be qualified.

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

Regarding (C) I don't see why we would want to do that. How can one 
process tap into a variable scoped by a different process? Inter-process 
communication should rely on sending messages around.

Assaf


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


-- 
"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]