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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tamie message

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


Subject: RE: [tamie] uc3 two areas of updates this week


Dale:
 
Could we add a bit more [xml] structure to the edge information:
rewrite:

   <Label2XPath>Accept,/OrderResponseSimple[AcceptedIndicator='true']</Label2XPath>

as:

   <Label2XPath label="Accept">/OrderResponseSimple[AcceptedIndicator='true']</Label2XPath>

 

Also, I believe we need somehow to add some message correlation info to this graph, so that we know which message the XPath condition/expression associated with each edge will apply to (because there could be many concurrent such transactions intertwined, while each single path across the LTS must select only related messages)

 

-jacques

 


From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: Thursday, March 12, 2009 10:40 AM
To: tamie@lists.oasis-open.org
Subject: [tamie] uc3 two areas of updates this week

1. LTS diagram: added loop indication, TTP (time to perform) failure edge, still experimenting with logically complex labels. Conjunctions are marked explicitly and to avoid multi edge graphs (multiple edges between two nodes), a disjunction is implicit currently.  A “true” label here is just an automatic “internal” transition, and if it is in a conjunct, it can be ignored. (p and true) equals p.

 

 

2. Another addition to uc3 is adding to Jacques enhanced LTS xml

 

There are now mappings of the document labels to XPaths for use in the conversion to scripts. I have not yet tried to produce the XML format of the original prototype. Instead the following is output at the moment.

 

A list of Nodes

Mixed List of Labels And of Edges

 

 Then the following

 

   <Label2XPath>PurchaseOrderRequest,/Order</Label2XPath>

   <Label2XPath>Accept,/OrderResponseSimple[AcceptedIndicator='true']</Label2XPath>

   <Label2XPath>AddDetailResponse,/OrderResponse</Label2XPath>

   <Label2XPath>Reject,/OrderResponseSimple[AcceptedIndicator='false']</Label2XPath>

   <Label2XPath>PurchaseOrderCancellation,/OrderCancellation</Label2XPath>

 

So, I have just produced xml container elements that contain “rewrite rules” for the DocumentEnvelopeLanguage (the ebBP term for a LTS  action/label/channel), to XPath.

 

Putting in namespace prefixes would be next. And if it is useful, I could output, prefix to namespace rules/maps in other containers. I would like to avoid tinkering with prefix redeclarations and scope, but it seems to me that whoever writes the XPath could simplify out those complexities when they stick the prefixes on the elements. I will check out some methods for various profiles of ebBP usage that will output the prefix to namespace rules eventually.

 

The ConditionGuardLanguage mappings are also underway. Several of the possible maps exploit signal message XPaths. When signals are not used, I am uncertain that there will be an XPath on a message. (The events might only be written to log files of the MSH on either or both ends. I think this would have to be information obtained from other sources than the ebBP because it involves some “private process/orchestration” side information.



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