OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [correction] RE: [ebxml-bp] XPath expression in ebxmlbp-2.0.4-Example-os-PIP7C7For2.04-en.xml


[Some cut and paste errors are removed.]

 

Andreas Schonberger asked:

 

XPath expression in ebxmlbp-2.0.4-Example-os-PIP7C7For2.04-en.xml

this example contains:
<Success nameID="Start_ST">
<FromLink fromBusinessStateRef="PIP7C7" conditionGuard="Success">
<ConditionExpression expression="//BusinessServiceInformation/ProcessState="Success"" expressionLanguage="XPath1" />
</FromLink>
</Success>

== it could not be assessed what this XPath expression is actually referencing.
Where is //BusinessServiceInformation/ProcessState defined?

   This example is derived from a sample BPSS 1.1 business process model from RosettaNet. Normally the convention for XPaths is that they apply to a document that is being exchanged. And after consulting my schemas for PIP7C7, there is an element in the PIP definition set, under the StandardBusinessDocumentHeader.xsd, which defines an optional element for XSD defined PIPs. (Earlier PIPs were available with DTD definitions, and no XSD definitions were issued.)

 

The complexType for the BusinessServiceInformation element is (look to the clause in bold and italics for BusinessServiceInformation/ProcessState).

 

   <xs:complexType name="BusinessServiceInformationType">
               
<xs:annotation>
                       
<xs:appinfo>
                               
<urss:Definition>The object allows the specification of the business
                                        service utilized within the partner company. This may or may
                                        not be the same as the information sent by the RNIF.
</urss:Definition>
                               
<urss:CreationDate>04/02/2005</urss:CreationDate>
                               
<urss:LastUpdatedDate>04/02/2005</urss:LastUpdatedDate>
                               
<urss:TypeVersion>1.0</urss:TypeVersion>
                       
</xs:appinfo>
               
</xs:annotation>
               
<xs:sequence>
                       
<xs:element name="ActionName" type="xs:string">
                               
<xs:annotation>
                                       
<xs:appinfo>
                                               
<urss:Definition>The name of Action. For RosettaNet
                                                  usually any of
                                                  Request/Confirm/Notify/Query/Response.
</urss:Definition>
                                       
</xs:appinfo>
                               
</xs:annotation>
                        
</xs:element>
                       
<xs:element name="ProcessIdentifier" type="xs:string">
                               
<xs:annotation>
                                       
<xs:appinfo>
                                               
<urss:Definition>The name of the PIP e.g. Notify of
                                                  Forecast Reply.
</urss:Definition>
                                       
</xs:appinfo>
                               
</xs:annotation>
                       
</xs:element>
                       
<xs:element name="ProcessReference" type="xs:string" minOccurs="0">
                               
<xs:annotation>
                                       
<xs:appinfo>
                                               
<urss:Definition>The URN for the PIP that includes
                                                  Cluster/Segment/Process pattern used to
                                                  identify the interface process (such as
                                                  PIP3A4)
</urss:Definition>
                                       
</xs:appinfo>
                               
</xs:annotation>
                       
</xs:element>
                       
<xs:element name="ProcessState" type="xs:string" minOccurs="0">
                               
<xs:annotation>
                                       
<xs:appinfo>
                                               
<urss:Definition>The business process (or service)
                                                  state of the sender of a document. When a
                                                  service receives this document, the receiver
                                                  may use the state as a
                                                precondition.
</urss:Definition>
                                       
</xs:appinfo>
                               
</xs:annotation>
                       
</xs:element>
                        <xs:element name="ServiceName" type="xs:string">
                               
<xs:annotation>
                                       
<xs:appinfo>
                                               
<urss:Definition>The name of the Business Activity
                                                  with the "Request/Confirm" part removed.
                                                  E.g., for the Activity "Request Purchase
                                                  Order"==
&gt; "Purchase
                                                Order".
</urss:Definition>
                                       
</xs:appinfo>
                               
</xs:annotation>
                       
</xs:element>
               
</xs:sequence>
               
<xs:attribute name="schemaVersion" type="xs:token"/>
       
</xs:complexType>

 

    IMO, the TC is really awaiting feedback from communities about both XSLT and XPath usage requirements. Interoperability in this area will probably need an additional TC report on guidelines for implementation for various usages.

 

We probably need to state, for example, that xpaths should reference element information items that are _somewhere_ specified under a Specification document within the BusinessDocument element. (In version 1.*, the specification could not document multiple schemas applicable to the BusinessDocument; this limitation has been corrected in ebBP 2.0.)

 

Again the TaMie TC (in OASIS) may help us work out a full use case for these language values in terms of their monitoring and testing script language.

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]