Re: issue resolution updates

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

Paul,
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.

-karsten


>
>With these decisions, there is still no mention of where business
>information objects come into play, as requested in issues 79, 80, 87, 92,
>94, 102, 103, 114.  If suitable business information objects can be found
>in the Business Library (per the TA Spec), there need be no reference to
>core components or to a CC context model.  Attributes should be taken from
>the standardized business information objects in the construction of the
>business document.  When business information objects are not available,
>core components from the Core Library, extended by the CC context model to
>be domain components should be used to create a candidate for a new
>business information object standard, and at the same time be used in the
>construction of the business document.
>
>Regards,
>
>Paul Levine
>__________________
>
>
>
>Resolution of issues, 4/17/2001
>
>In metamodel meeting today we decided on the following issues:
>
>1. We will rename DocumentType to BusinessDocument (partially resolved
>issues
>102/103/114) 2. We will (re-)introduce the DocumentEnvelope, but as an
>optional layer: A document flow can have a single BusinessDocument, or a
>DocumentEnvelope. Who will make a proposal for this? (Part of issue 120)
>3. We will not introduce the explicit notion of structured and unstructured
>documents. All primary documents (element BusinessDocument) are expected to
>be
>XML, defined in a Schema (or DTD), even if all they are is a wrapper around
>some "unstructured" segment and/or the holder of a set of attachments. 4.
>We
>will rename Schema to DocumentSpecification (related to issues 102/103/114)
>5.
>We will leave cardinality between the renamed entities
>DocumentSpecification
>and BusinessDocument as one-to-many. This means that a new business
>transaction must be defined for each flavor of its document exchange. For
>example CreatePurchaseOrder_OAG using OAG documents, and
>CreatePurchaseOrder_X12 using X12, etc. etc. The group feels this is the
>only
>safe thing to do. Any attempt to allow generic transactions with
>parameterized
>document choice is too ambitious (whimps!). 6. We leave logicalModel as the
>only linkage to the CC context model. So in the renamed
>DocumentSpecification
>element "location" points to where the actual content model of the
>BusinessDocument is, and "logicalModel" points to where the CC context
>model
>for the BusinessDocument is. If the latter is blank, the BusinessDocument
>is
>assumed to not have been created using CC context model. 7. There was no
>support for simplifying ebXML process specification by allowing Business
>Transaction to be its own BinaryCollaboration, instead of requiring a
>wrapping
>BinaryCollaboration. Proposal dropped (whimps!).
>
>
>------------------------------------------------------------------
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>
>
>------------------------------------------------------------------
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org