[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tamie] Groups - UC3 LTS draft XML, version .1 (uc3-edges.xml) uploaded
I have looked at the UBL 2 directory, xsdrt and here is my guess about the information as represented in ebBP 2
<!--Order-->
<BusinessDocument name="Order" nameID="Request1">
<Documentation/>
<ConditionExpression expressionLanguage="XPath2" expression="/Order"/>
<Specification location="http://docs.oasis-open.org/ubl/os-UBL-2.0/xsdrt/maindoc/UBL-Order-2.0.xsd";
name="urn:oasis:names:specification:ubl:schema:xsd:Order-2" nameID="Order-2"/>
</BusinessDocument>
<!--Accept-->
<BusinessDocument name="OrderResponseSimple" nameID="Response1">
<Documentation></Documentation>
<ConditionExpression expressionLanguage="XPath2" expression="/OrderResponseSimple[AcceptedIndicator='true']"/>
<Specification location="http://docs.oasis-open.org/ubl/os-UBL-2.0/xsdrt/maindoc/UBL-OrderResponseSimple-2.0.xsd";
name="urn:oasis:names:specification:ubl:schema:xsd:OrderResponseSimple-2" nameID="OrderResponseSimple0"/>
</BusinessDocument>
<!--Order Response that Adds Detail or Changes-->
<BusinessDocument name="OrderResponse" nameID="Response2">
<Documentation/>
<ConditionExpression expressionLanguage="XPath2" expression="/OrderResponse"/>
<Specification location="http://docs.oasis-open.org/ubl/os-UBL-2.0/xsdrt/maindoc/UBL-OrderResponse-2.0.xsd";
name="urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2" nameID="AddDetailResponse1"/>
</BusinessDocument>
<!--Reject-->
<BusinessDocument name="OrderResponseSimple" nameID="Response3">
<Documentation/>
<ConditionExpression expressionLanguage="XPath2" expression="/OrderResponseSimple[AcceptedIndicator='false']"/>
<Specification location="http://docs.oasis-open.org/ubl/os-UBL-2.0/xsdrt/maindoc/UBL-OrderResponseSimple-2.0.xsd";
name="urn:oasis:names:specification:ubl:schema:xsd:OrderResponseSimple-2" nameID="OrderResponseSimple1"/>
</BusinessDocument>
<!--Purchase order Cancellation Document-->
<BusinessDocument name="PurchaseOrderCancellationSpecification" nameID="Cancel1">
<Documentation/>
<ConditionExpression expressionLanguage="XPath2" expression="/OrderCancellation"/>
<Specification location="http://docs.oasis-open.org/ubl/os-UBL-2.0/xsdrt/maindoc/UBL-OrderCancellation-2.0.xsd";
name="urn:oasis:names:specification:ubl:schema:xsd:OrderCancellation-2" nameID="SpecificationCancellation1"/>
</BusinessDocument>
The next question is how to transform this and associate it with the label on the edge of a LTS graph for the process.
Jacques sketched the following target format in an earlier POC on LTSes and script generation.
<Edge from="PurchaseOrderRequestAndConfirm1" to="CancelOrderActivity1" label="PartialPurchaseOrderResponse and success">
<condition>
<event>tamie:content/wsi:message/wsi:messageContents/s:Envelope/s:Body/PurchaseOrderResponse//ConfirmationCode['partial']</event>
<correlation name="C1">tamie:content/wsi:message/wsi:messageContents/s:Envelope/s:Body/PurchaseOrderRequest/ApplicationArea/Receiver/LogicalID</correlation>
</condition>
</Edge>
I have not yet tackled the correlation part of this expanded label on the transition.
Now to a comment on your proposals.
I am guessing that some of the differences between the first and the second proposals involve namespace prefixes, and the fact that there is not a conventional way (outside of the Xpointer framework) for describing within ebBP attributes, what namespace a prefix is associated with. We could just add an xmlns:prefix to the instance document. I had expected that the combination of location and name attributes in Specification would be used, when an XSD was involved, to indicate "the" namespace; for example,
<Specification location="http://docs.oasis-open.org/ubl/os-UBL-2.0/xsdrt/maindoc/UBL-Order-2.0.xsd";
name="urn:oasis:names:specification:ubl:schema:xsd:Order-2" nameID="Order-2"/>
But there might be multiple prefixes needed in an XPath, collectively associated with multiple namespaces.
In a minor version, or errata, ebBP could add refinements promoting more interoperable and general capabilities in this area. TaMie could make up some conventions for its use, and pass those along to ebCore, the TC that maintains ebBP and ebCPPA and eventually other ebXML OASIS specifications.
So, for example, we could add XPointers and these will permit us to declare namespace prefix to URI associations.
It is already known that the XSLT expressions used in variable assignments need to be escaped within the attribute values. And we need to have a convention for what document is an input to a given XSLT script. Are XSLT fragments allowed? What context should they be inserted into? Etc. etc. All these issues were deferred until some usage patterns indicated needs, and then steps for standardized, interoperable conventions could be added. For the moment, the treatment of condition expression values is implementation dependent.
For these reasons, I suggest we try to keep the expressions fairly simple but be on the lookout for a list of issues to submit to ebCore for future standardization.
I am going to go back to work on the XSLT to produce a target output a bit closer to what Jacques used in the POC. Maybe we can discuss on the call what UBL requires in terms of logical document definition when using XPath etc.
-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Tuesday, February 24, 2009 4:10 PM
To: Moberg Dale; TAG TC
Subject: Re: [tamie] Groups - UC3 LTS draft XML, version .1 (uc3-edges.xml) uploaded
idea for slightly improved xpaths which are agnostic of xml
ancestors (need to check xpath syntax)
//*[local-name='OrderResponseSimple']/*[local-name='AcceptedIndicator']='true'
//*[local-name='OrderResponse']
//*[local-name='OrderResponseSimple']/*[local-name='AcceptedIndicator']='false'
- Steve
2009/2/24 Moberg Dale <dmoberg@axway.com>:
> Right, I was looking for exactly that sort of information you are providing to put back into the ebBP model (where it is then projected out for the LTS graph).
>
> I think the LTS is only a "bare bones" process description. There is a lot more to a BP specification than just choreography or orchestration.
>
> Eventually the LTS input will become an annotated LTS, where the annotations are for QOS, timers, control signals, security, reliability, etc. These will then connect with concrete stuff on the wire that eTSL needs to actually work. But LTS (unextended) will provide the "GCD" for all bare bones process descriptions from other BP modeling notations, like UML message sequence diagrams, etc.
>
> If you are on the call today, we can use the conference to check out the edits that are needed to make the XPaths connect to UBL documents.
>
> Dale Moberg
>
>
>
> -----Original Message-----
> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
> Sent: Tuesday, February 24, 2009 12:30 PM
> To: Moberg Dale
> Cc: tamie@lists.oasis-open.org
> Subject: Re: [tamie] Groups - UC3 LTS draft XML, version .1 (uc3-edges.xml) uploaded
>
> I'm guessing that the XPaths might need to be concrete for this
> to work with eTSM.
>
> If the language used is UBL 2.0 then the XPaths for
>
> Accepted PartialAcceptance Declined
>
> are:
>
> /OrderResponseSimple/cbc:AcceptedIndicator='true' /OrderResponse
> /OrderResponseSimple/cbc:AcceptedIndicator='false'
>
> Does the 'LabelXPath' need to be concrete as follows or am I missing
> the point?
>
> <LabelXPath>
> PORequestResponses,/OrderResponseSimple/cbc:AcceptedIndicator='true'
> /OrderResponse /OrderResponseSimple/cbc:AcceptedIndicator='false'
> </LabelXPath>
>
>
> - Steve
>
>
> 2009/2/24 <dmoberg@us.axway.com>:
>> XML describing the nodes, edges, and labels of the LTS for uc3 as derived
>> from the ebBP model of uc3.
>>
>> -- Dale Moberg
>>
>> The document named UC3 LTS draft XML, version .1 (uc3-edges.xml) has been
>> submitted by Dale Moberg to the OASIS Testing and Monitoring Internet
>> Exchanges (TaMIE) TC document repository.
>>
>> Document Description:
>> XML describing the nodes, edges, and labels of the LTS for uc3 as derived
>> from the ebBP model of uc3.
>>
>> This file will eventually supply Jacques XSLTs for producing scripts and
>> information for events to be caught in monitoring/testing this choreography
>> by relating the script to the execution trace of events from running the
>> process.
>>
>> Still needs to have the timer information and control/signal message
>> information output, as well as much other QOS information.
>>
>> View Document Details:
>> http://www.oasis-open.org/committees/document.php?document_id=31402
>>
>> Download Document:
>> http://www.oasis-open.org/committees/download.php/31402/uc3-edges.xml
>>
>>
>> PLEASE NOTE: If the above links do not work for you, your email application
>> may be breaking the link into two pieces. You may be able to copy and paste
>> the entire link address into the address field of your web browser.
>>
>> -OASIS Open Administration
>>
>
>
>
> --
> Stephen D. Green
>
> Document Engineering Services Ltd
>
>
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>
--
Stephen D. Green
Document Engineering Services Ltd
http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]