[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: FW: [wsbpel] Proposed resolution of Issue 39 - Inconsistent syntax for query attribute values in spec examples
Glenn made a good point - the use of "type" vs "element" attribute in wsdl:part may have significant impact on the binding and the wired message. It reminds me that as a group, we may need to ask ourselves the following questions sooner or later. Based on the answer, we may need to tune up the WSDL examples used in the current draft. - Which version of WSDL do we want to use? WSDL1.1 or WSDL 1.2 ( or I should say the deliverable of the w3c WSD working group, it might be called WSDL 2.0 eventually)? - Do we care about WS-I Basic Profile (BP) 1.0 (see [1])? - Do we want to indicate a preference for RPC style in our examples? Since BPEL only uses the wsdl:portType definition and the binding definition is typically not available, the last question may seem irrelevant. But if we want to continue to use wsdl1.1, we may need to consider being compliant with WS-I BP1.0, then the wsdl:part definition does have significant impact on what kind of bindings can be used and how the wired message may look like. Basically, according to BP1.0, when soap over http is concerned, - a wsdl:part which uses the @type attribute to reference a schema type can only be used by a RPC style operation - for RPC style operations, the wired message must have a wrapper element which is the child of soap:body and has the same name as the operation. Part accessors have the same name as the corresponding wsdl:part - a wsdl:part which use the @element attribute to refer to a global element can only be used by a Document style operation - for Document style operations, in the wired message, the child of soap:body must be the element referenced by the part definition In most, if not all, of the WSDL examples used in the current draft, wsdl:part uses @type attribute. According to BP1.0, *THIS IMPLIES THAT RPC STYLE IS CHOSEN*, I suspect that is the real intention of the authors. IMHO, as a process definition language, BPEL should at least provide balanced number of examples that can be used by document style. If wsdl1.2 is to be used, of course the examples need to be changed, but it will be a different story. Though I am in favor to use a standard version of WSDL, I am not sure if it's practical for us to use wsdl1.2 given that we have a very aggressive schedule and wsdl1.2 is still under heavy construction. Best Regards, Kevin [1] http://www.ws-i.org/Profiles/Basic/2003-06/BasicProfile-1.0-BdAD.html (section 5.3.1 is most relevant) -----Original Message----- From: Glenn Mi [mailto:gmi@collaxa.com] Sent: Thursday, July 31, 2003 11:51 AM To: Ugo Corda; edwink@collaxa.com Cc: wsbpel@lists.oasis-open.org Subject: RE: FW: [wsbpel] Proposed resolution of Issue 39 - Inconsistent syntax for query attribute values in spec examples Ugo: You are right about the example on page 92. It's using a "type=" in part definition, so the partName should appear in the actual message. For the example on page 38, I agree with you that providing a message definition will clarify what the query string should look like. I just want to bring to attention that the queryString depends on how you define the message part, that is, if you use "type=" or "element=" in <part>. Glenn Mi 650-801-6297 Collaxa, Inc. 1600 Bridge Parkway Redwood Shores, CA 94065 -----Original Message----- From: Ugo Corda [mailto:UCorda@SeeBeyond.com] Sent: Thursday, July 31, 2003 9:46 AM To: edwink@collaxa.com Cc: wsbpel@lists.oasis-open.org Subject: RE: FW: [wsbpel] Proposed resolution of Issue 39 - Inconsistent syntax for query attribute values in spec examples Thinking a little more about this, I think Glenn's point can only apply to the example on page 38, where there is no declaration for the part "identification" and as such it could be anything. In the case of the example on page 92, all the parts are defined using a type, so the corresponding part elements have to have a name identical to the part name. Ugo -----Original Message----- From: Ugo Corda Sent: Thursday, July 31, 2003 9:09 AM To: edwink@collaxa.com Cc: wsbpel@lists.oasis-open.org Subject: RE: FW: [wsbpel] Proposed resolution of Issue 39 - Inconsistent syntax for query attribute values in spec examples Edwin, I see Glenn's point. But my assumption was that the examples I was referring to used the convention of choosing a part name that is identical to the corresponding element name (as it must be true for the example on page 49). The examples don't have a full definition of the part elements, so it is impossible to say that my assumption is correct. I just inferred it from some aspects of these examples. For instance, in the example on page 92, the part "shipNotice" is defined on page 90 to be of type shipNotice and I thought that naturally the corresponding element would have the same name (and that ShipNoticeHeader would be a child of that element). Maybe the best way to resolve the issue is to provide a complete definition of the elements associated with the parts used in the examples, so that no misunderstanding can result from reading them. (For sure I know people in my company found these examples confusing when it comes to deciding how to implement the query attribute processing). Ugo -----Original Message----- From: Edwin Khodabakchian [mailto:edwink@collaxa.com] Sent: Wednesday, July 30, 2003 8:31 PM To: Ugo Corda Cc: wsbpel@lists.oasis-open.org Subject: FW: [wsbpel] Proposed resolution of Issue 39 - Inconsistent syntax for query attribute values in spec examples FYI. Please let me know if you agree with Glenn's point of view. Thank you. Edwin From: Glenn Mi [mailto:gmi@collaxa.com] Sent: Wednesday, July 30, 2003 8:07 PM To: edwink@collaxa.com; Subject: RE: Inconsistent syntax for query attribute values in spec examples I am not sure I agree with Ugo . What if the messageType is defined as: <message name="taxpayerInfo"> <part name="identification" element="tns:mytype"/> </message> and tns:mytype is defined as: <schema> <element name="socialsecnumber" type="xsd:string"/> </schema> Notice this is using a doc/literal style of SOAP. Then the top level element is <socialsecnumber>. And the query "/socialsecnumber" is correct. Glenn Mi -----Original Message----- From: Edwin Khodabakchian [mailto:edwink@collaxa.com] Sent: Wednesday, July 30, 2003 7:35 PM Subject: Inconsistent syntax for query attribute values in spec examples Do you guys have any take on this? From: Ugo Corda [mailto:UCorda@SeeBeyond.com] Sent: Wednesday, July 30, 2003 7:05 PM To: wsbpel@lists.oasis-open.org Subject: [wsbpel] Proposed resolution of Issue 39 - Inconsistent syntax for query attribute values in spec examples As a champion for Issue 39 I would like to start the discussion by proposing what I see as a simple resolution. If no unforeseen problems are discovered that require extensive discussions, I would also propose that we finalize the resolution of this issue during the next meeting on August 6. Thank you, Ugo Proposed resolution: =============== The example on page 49 is correct. The examples on page 38 and 92 need to be modified as follows: Page 38: <bpws:propertyAlias propertyName="tns:taxpayerNumber" messageType="txmsg:taxpayerInfo" part="identification" query="/socialsecnumber"/> becomes: <bpws:propertyAlias propertyName="tns:taxpayerNumber" messageType="txmsg:taxpayerInfo" part="identification" query="/identification/socialsecnumber"/> Page 92: <bpws:propertyAlias propertyName="tns:shipOrderID" messageType="sns:shippingNoticeMsg" part="shipNotice" query="/ShipNoticeHeader/shipOrderID"/> becomes: <bpws:propertyAlias propertyName="tns:shipOrderID" messageType="sns:shippingNoticeMsg" part="shipNotice" query="/shipNotice/ShipNoticeHeader/shipOrderID"/> (The other four propertyAlias elements in the same example on page 92 should also be modified in a similar way). Rationale: ======= Section 8.2, Defining Properties, immediately after the syntax description for a propertyAlias definition says: "The interpretation of the message, part, and query attributes is the same as in the corresponding from-spec in copy assignments (see Assignment)". Section 14.3, Assignment, says: "For XPath 1.0, the value of the query attribute MUST be an absolute locationPath (with '/' meaning the root of the document fragment representing the entire part). It is used to identify the root of a subtree within the document fragment representing the part." According to the XPath 1.0 data model (Sec. 5.1 of the XPath 1.0 Recommendation), "The root node is the root of the tree. [...] The element node for the document element is a child of the root node". If we apply this rule to the "document fragment representing the entire part", then any absolute location path will be of the form: "/part-name/...". For instance, if we look at the example on page 92 the document fragment representing the "shipNotice" part would look something like this: <shipNotice> <ShipNoticeHeader> <shipOrderID> ... </shipOrderID> </ShipNoticeHeader> ... </shipNotice> and the absolute location path that selects the shipOrderID node has to be "/shipNotice/ShipNoticeHeader/shipOrderID".
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]