[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
Dale, My reason for trying to leave the prefixes and namespaces out of the XPath expressions is partly the fact that I can't think how to cater for them in the interpretation of the event board. I've had all sorts of problems in the past when doing XSLT transformations in cases where the prefixes and the namespaces aren't known. The only way, with XSLT 1.0, it seems, to write which stylesheets which will work whatever the namespaces and prefixes of the transformed instances are, is to leave both the namespace and the prefix out of all XPaths in the stylesheet. I'm not sure how this issue is handled in XSLT 2 though (Mr Kay did assure me once it would not be an issue with version 2 but I never did find out how that is). So if there is a prefix in the XPath and the instance uses a different one (as well it might, of course, as per XML Namespaces spec) then the XPath will need to have that exact prefix declared in the stylesheet header for it to 'know' that the prefix and the one in the XPath are equivalent. So this would necessitate (at least in XSLT 1.0) that the namespace be known when the stylesheet is written. (I could not find any way to dynamically introduce the namespace by analysis of the instance at runtime to grab its namespace - seems to be a logic problem - determinism, etc.) Therefore, taking it that we don't want to have to generate a separate stylesheet for every possible document type (one for UBL Invoice, one for GS1 Order, one for...) - though maybe that is potentially on the table still - I thought it should be possible and preferable to interrogate the XPaths in the Condition expressions of the business process documents to obtain the raw XPath then extract (using an algorithm/XSLT function(s)) the prefix/namespace-agnostic XPath suitable for actual execution. I guess we need to see whether this will be possible for not just our use case 3 but others too. Regarding namespaces in ebBP, I've always taken these to be just for documentary definition, not for execution. UBL has at least three namespaces (and two or three prefixes) for every document. I can't see how a processor could cope with analysing the ebBP to extract that information generically even if it was in the ebBP - nor whether it would be necessary for the use of an ebBP instance. I'm guessing an XPath profile of the ebBP would need to be defined to make it executable in the way we want it too be. In particular, all the necessary information would have to be contained in the condition expressions which would have to be limited in their expression language and mainly limited to XPath if the purpose of the LTS and eTSM is one which involves a comparison between the condition guard expression and the actual events in the board. What we might be able to work towards is an idea of what such a profile of ebBP (perhaps BPEL too) might entail. Best regards Steve 2009/3/3 Moberg Dale <dmoberg@axway.com>: > 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 > -- 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]