OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: issue resolution updates

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.


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
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
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.
will rename Schema to DocumentSpecification (related to issues 102/103/114)
We will leave cardinality between the renamed entities
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
safe thing to do. Any attempt to allow generic transactions with
document choice is too ambitious (whimps!). 6. We leave logicalModel as the
only linkage to the CC context model. So in the renamed
element "location" points to where the actual content model of the
BusinessDocument is, and "logicalModel" points to where the CC context
for the BusinessDocument is. If the latter is blank, the BusinessDocument
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
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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC