[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 103 - Good Idea!
Hi, Assaf, Satish and Ugo, (1) For variable name, both Satish and Assaf have convinced me that a non-qualified name should be enough. And, BPEL variable should stay private within the process. Variable referencing among BPEL is one big can of worms, that we even don't want to think about. [My mistake to mention it ... :-) ] (2) We should use unqualified name when possible. For WSDL 1.1 part name, I agree that we should use local name. (3) Assaf Arkin wrote: > And for WSDL 1.1: > > $variable (one unnamed part, complex type) That is a good catch of a usecase in WSDL 1.1. Just want to supplement, I believe unnamed part can be simple type also. When simple type, it should be similar to a BPEL simple type variable also. When complex type, I think the xpath would look like: $variable[/ns:wsdlMsgName/...] I hope this sounds right to you guys. (4) Assaf suggested: In WSDL 2.0, $variable/ns:element[/ns:subElement] In WSDL 1.1, $variable/partName/ns:element I was wondering whether it make sense to add a WSDL QNAME (ns:wsdlMsgName) like the following for WSDL 1.1: $variable/ns:wsdlMsgName/partName/... then the syntax would be more symmetrically between WSDL 1.1 and 2.0 ns:wsdlMsgName => ns:element partname => subElement The BPEL code migration may be easier from WSDL 1.1 to 2.0 Anyway, I really need to do more research and homework on WSDL 2.0 (especially the sequence part) first before voicing further opinions on how to use XPath to deal with WSDL 1.1 and 2.0 message in a more forward-compatible way. Sorry about putting my own brainstorming thoughts on how to use XPath for WSDL 1.1 in the public. :-) Regards, Alex Yiu Assaf Arkin wrote: > Correction. Lastest draft says the message type is always an element, > but still defines the message as complexType sequence of elements in > the RPC encoding section. Leaves me confused. > > So for element it would be: > > $variable/ns:element[/ns:subElement] > > For sequence it would be: > > $variable/ns:elementFromSequence > > And for WSDL 1.1: > > $variable (one unnamed part, complex type) > $variable/partName/ns:element (multiple parts, elements) > > Assaf > > Assaf Arkin wrote: > >> 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. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >> 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]