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: FW: [wsbpel] Proposed resolution of Issue 39 - Inconsistent syntax for query attribute values in spec examples


Title: 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]