[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Remove all Documents? was Re: issue resolution updates
As I read the ebXML Requirements Spec, a business process definition encompases the information exchanged within the specification of the business collaboration. I understood the Tokyo agreement to be an expedient in the interest of time to meet specification deadlines, but requiring an unambiguous handoff from the BP metamodel to the CC metamodel as described in their respective specifications. However, there should ideally be one ebXML metamodel, and that should be an objective of ebXML-2. For now, I don't have a problem with expecting the CC documents to cover the analysis and structure of business documents, as long as the ebBPSS and CC metamodels are clearly aligned and that the CC specifications provide for business documents to be constructed from business information objects, which are in turn constructed from core components extended by context. Response to my comment to the CC PT on alignment was that the alignment was understood to have been accomplished in Vancouver, and if not, it "needs to be reflected in the documents containing the UML models, and not this one," i.e., "The role of context in the re-usability of core components and business processes." Response to my comment on business document construction was that "this specification is entirely about how to use context definition to "create new objects" in a way that will be interoperable. The change I proposed was determined to not belong in the above cited specification. Accordingly, the proposed change was included as Section 9.2 in the Business Process and Business Information Analysis Overview [bpOVER]. Regards, Paul Levine James Bryce Clark To: Karsten Riemer <Karsten.Riemer@east.sun.com> <jbc@lawyer.c cc: "Paul R. Levine" <plevine@telcordia.com>, om> ebxml-bp@lists.ebxml.org, (bcc: Paul R. Levine/Telcordia) Subject: Remove all Documents? was Re: issue resolution 04/18/01 updates 08:49 PM Karsten, this sounds like pretty radical surgery, and at first blush I am having trouble conceptualizing the degree to which logical model validation would be achievable after that triage. Doesn't this really get you to the same place as your e-mail from Africa? (Cardinality change, where transactions take 0..* documents instead of 1,2? ) In a hypothetical zero-documents world: 1. I think we would be allowing each schema (lower case "s", e.g., X12, RNIF, OAG) to bring over its own level of reliability of contract production -- instead of imposing the constraints in the somewhat RNIF-like UMM. Is that a good thing? Certainly it would make for easier adoption by all kinds of other communities, including non-UMM-users of UML. On the other hand, we lose some of the opportunity to logically compare apples to apples, and we lose the advantage of reliability and stability perceived by some in the binary pairing model. 2. Don't we lose some of the signals too? I'm not sure how the DSIG parameter or 'receiptAcknowledgement' would work, if there is a complex or indeterminate association between the doc that asks for the parameter, and the document(s) that [respond] to it and therefore should conform to the parameter. It might be a solvable problem, but it seems a little late to crack that tough nut in a reliable and stable manner for 1.0. Jamie At 08:42 AM 4/18/2001 , Karsten Riemer wrote: >Since the Specification Schema no longer has a DocumentModel, I propose to >remove all associated references to the analysis and structure of >BusinessDocuments from the Specification Schema, and leave that up to CC >documents as agreed in Tokyo. I think we should try to make the Specification >Schema shorter, not longer.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC