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


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!).



[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