[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Regarding ebBP resuing ebBP packages
Hi Sacha, I did not find the sample signals package in the 2.04 zip packages. Here attached is one I used in testing. Oxygen will process the xpointers using the element scheme (you have to run an identity xslt transform to make it replace the xinclude though). It has problems with using just ids to locate the element. It appears to expect xml:id on the element. But we cannot put xml:id on the element because we already have the nameId attribute on the element and apparently two id values (even if unique in the document) are not allowed on an element. Seems like an unnecessary restriction to me but it is probably just following a spec :-) Dale Moberg -----Original Message----- From: Sacha Schlegel [mailto:sacha@schlegel.li] Sent: Tuesday, April 24, 2007 2:21 PM To: Dale Moberg Cc: Stephen Green; Monica J. Martin; ebXML BP Subject: RE: Regarding ebBP resuing ebBP packages Hi Dale I will look have a look at the CollaborationActivity tomorrow and will follow up here on the list. Thanks for the help with signals. Sacha Am Montag, den 23.04.2007, 10:06 -0700 schrieb Dale Moberg: > Sacha S. writes: > > I had another look at the ebBP Steve has done ... the one listed on the > ebBP site (and attached to this email) demonstrating the use of reusing > ebBP packages. > > I think we could put all ebBP signals into a separate package (separate > file) for reuse. > > Dale>> I think a sample signals package file for the default signals > should be included in one of the zip files. > > Whether all signals will be used in the target package is probably no > big issue, > This would eliminate the copying Steve mentioned in the comment. I would > need to double check the scoping rules but I guess it would be OK. > > Dale>> I think we recommended (possibly required) that imports import > entire packages. So place the xi:include instructions where packages can > be inserted. > > The BusinessDocuments > we could also xinlcude ... I would think with something like > <xi:include href=... > xpointer="xpointer(/ProcessSpecification/BusinessDocument) we would get > all BusinessDocuments from the included ProcessSpecification. > > Dale>> Well, we were going to insert xml chunks by complete packages. > The motive for doing this was, I think, that there would be less > likelihood of garbage inserts. Also recall that tooling has been slow to > support the xpointer scheme itself. Using the "element" scheme inside > the xpointer syntax might be more widely supported. That means that you > might consider pointing at a specific Package element in your xpath... > > What I realise is that in the new (custom) business collaboration we do > not reuse the business collaborations but just the business transactions > from the included packages. > > Dale>> Not sure why we could not reuse business collaborations? Put them > into a package, xinclude them, and then reference them within a > CollaborationActivity. Why would that not work for your use cases? You > will need to rebind the Role values, of course. But that is part of the > CollaborationActivity functionality. > > > > Would it make sense to reuse complete Business Collaborations and to > reference them like a business transaction activity in a business > collaboration? > > Dale>> I am not sure I understand. CollaborationActivity should be a > supported way to do this. > > This would mean that the ToLink element inside the Start element as well > > as the FromLink, ToLink of Transition (and other constructs using those > Linking elements) would need to allow the reference of business > collaborations > instead of simply business transaction activities. A business > collaboration > will always have a final state (success or failure) so we can use those > states for transitions to further Business Collaborations or BTA's. Such > a > reference to a business collaboration would need need Performs elements. > > Is this completely off? Against some common understanding of ebBP? > > Dale>> Check on the CollaborationActivity. See whether it has enough > functionality to do what you are envisioning. I may not understand the > problem you are facing correctly so please follow up if there needs to > be something else done. There is a lot of support for reuse and library > design in version 2.0. > > Regards > > Sacha >
<?xml version="1.0" encoding="UTF-8"?> <ProcessSpecification xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://docs.oasis-open.org/ebxml-bp/ebbp-2.0 /Schemas/ebbp-2.0.3.xsd" xmlns="http://docs.oasis-open.org/ebxml-bp/ebbp-2.0" name="signals-package" nameID="sp23" uuid="urn:ebBP:signalsPackage" instanceVersion="1" specificationVersion="2"> <Package name="bpss:signals:2.0" nameID="signal1"> <Signal name="ra" nameID="ra2"> <Specification location="http://docs.oasis-open.org/ebxmlbp/ebbp-signals-2.0" name="ReceiptAcknowledgement" nameID="rabpss2"/> </Signal> <Signal name="rae" nameID="rae2"> <Specification location="http://docs.oasis-open.org/ebxmlbp/ebbp-signals-2.0" name="ReceiptAcknowledgementException" nameID="raebpss2"/> </Signal> <Signal name="aa" nameID="aa2"> <Specification location="http://docs.oasis-open.org/ebxmlbp/ebbp-signals-2.0" name="AcceptanceAcknowledgement" nameID="aabpss2"/> </Signal> <Signal name="aae" nameID="aae2"> <Specification location="http://docs.oasis-open.org/ebxmlbp/ebbp-signals-2.0" name="AcceptanceAcknowledgementException" nameID="aaebpss2"/> </Signal> <Signal name="ge" nameID="ge2"> <Specification location="http://docs.oasis-open.org/ebxmlbp/ebbp-signals-2.0" name="GeneralException" nameID="gebpss2"/> </Signal> </Package> </ProcessSpecification>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]