[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 103 - Good Idea!
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. > -- "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]