issue resolution updates

["Paul R. Levine" <plevine@telcordia.com>]

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