ebxml-ccbp-context message


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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: BP DTD first draft and comments (Fwd)


Hi,
I would like to have a discussion of this topic at next tuesday's metamodel
meeting. Antoine has done some good work here to explore the complexities of
mapping from our current UML model to a 'user-friendly' XML format. It brings
up a lot of issues, in addition to the ones that Antoine raised. So if you
plan to attend next Tuesday's meeting, please see if you can find time to read
Antoine's message and DTD's in advance. Antoine, could you send us a brief
description of the actual steps you took to arrive at these DTD's?
I attach Antoine's dtd as amended by Betty Harvey,

thanks,
-karsten

>----------------Begin Forwarded Message----------------<

Date: Wed, 20 Sep 2000 17:36:26 +0100
From: LONJON Antoine <ALonjon@MEGA.com>
Subject: BP DTD first draft and comments
To: ebXML-BP@lists.ebxml.org
Cc: "'Hirotaka Hara'" <hara@soft.flab.fujitsu.co.jp>,
        "'jjdubray@exceloncorp.com'" <jjdubray@exceloncorp.com>

Dear team members,

This is only a preliminary draft of the BP DTD. It only covers the BOV as it
contains the main data we want to store in an ebXML repository.
More can come if necessary. Especially, we are waiting the definition
of BusinessDocument from the CC/BP team.

Several comments on the current model:
1. The XML definition must be as simple as possible: corresponding documents
will be interpreted by software.
2. Inheritance of association is a difficult to interpret and should be
avoided as far as possible.
3. I have an issue with BusinessPartner and Functional role:
If we want to define CommercialTransactions as independant elements,
roles are then composite of CommercialTransactions.
So, in the version, I did not take the Party element into account.
4. When you read the DTD, it apperas that the OjectflowState step to get to
the document
is unnecessary. It is only the consequence of using the ActivityDiagram
metamodel.

An example of overusing inheritance:
CommercialTransactionActivity is a subtype of ActionState and
BusinessCollaborationProtol is a subtype of ActivityGraph.
What should we be using from the ActivityGraph to choreograph the
CommercialTransactions in a BusinessCollaborationProtocol:
SimpleTransition/Condition/fork/Branch, .....
The inheritance relationship does not state anything about this. We do not
want the DTD to cover all the ActivityGraph.

I've made two proposals, one for the CommercialTransaction
(CommercialTran.png) and the other one for BusinessCollaborationProtocol
(BusinessCollProt.png) that express the BOV mapping into XML.
The UML model shall be readden as follow:
Each composition association leads to an ELEMENT in XML
The other associations lead to ID/IDREF pairs.

I will provide shortly an XSD version of the DTD.

Antoine LONJON
Chief Architect
33 1 42 75 40 30
alonjon@mega.com
 


>----------------End Forwarded Message----------------<

<?xml version="1.0"?>

<!-- Eleminated extraneous characters. Added BusinessCollaborationProtocol to
     content model.  -->

<!ELEMENT CommercialTransaction (RequestActivity | RespondActivity | Role |
                                 BusinessCollaborationProtocol)?>

<!ATTLIST CommercialTransaction

          id ID #IMPLIED

          Name CDATA #REQUIRED

          IsSecuredTransportRequired CDATA #REQUIRED>



<!ELEMENT RequestActivity (RequestDoc)>

<!ATTLIST RequestActivity

          isAuthorizationRequired CDATA #REQUIRED

          isNonRepudiationRequired CDATA #REQUIRED

          timetoPerform CDATA #REQUIRED

          timetoAcknowledgeReceipt CDATA #REQUIRED

          timetoAcknowledgeAcceptance CDATA #REQUIRED

          retryCount CDATA #REQUIRED

          isNonRepudiationOfReceiptRequired CDATA #REQUIRED

          Name CDATA #REQUIRED

          Role IDREF #IMPLIED

          receivedDoc IDREF #IMPLIED>



<!ELEMENT RespondActivity (ResponseDoc)>

<!ATTLIST RespondActivity

          isAuthorizationRequired CDATA #REQUIRED

          isNonRepudiationRequired CDATA #REQUIRED

          timetoPerform CDATA #REQUIRED

          timetoAcknowledgeReceipt CDATA #REQUIRED

          timetoAcknowledgeAcceptance CDATA #REQUIRED

          isIntelligibleCheckRequired CDATA #REQUIRED

          Name CDATA #REQUIRED       

          Role IDREF #IMPLIED

          receivedDoc IDREF #IMPLIED>


<!-- Corrected the EMPTY Declaration -->

<!ELEMENT Role EMPTY>

<!ATTLIST Role

          Name CDATA #REQUIRED

          id ID #IMPLIED>



<!ELEMENT RequestDoc (Document)>



<!ELEMENT ResponseDoc (Document)>

<!-- Corrected the EMPTY Declaration -->

<!ELEMENT Document EMPTY>

<!ATTLIST Document

          Name CDATA #REQUIRED>



<!ELEMENT BusinessCollaborationProtocol (Activity*)>

<!ATTLIST BusinessCollaborationProtocol

          Name CDATA #REQUIRED

          Initial IDREFS #IMPLIED>

<!-- Added the element name 'Activity' to the ATTLIST
     declaration.
--> 

<!ELEMENT Activity (SimpleTransistion)>

<!ATTLIST Activity
          Name CDATA #REQUIRED

          isConcurrent CDATA #REQUIRED

          timeToPerform CDATA #REQUIRED

          id ID #IMPLIED

          CommercialTransaction IDREFS #IMPLIED>



<!ELEMENT SimpleTransistion (Guard*)>

<!ATTLIST SimpleTransistion

          Name CDATA #REQUIRED

          TargetActivity IDREFS #IMPLIED>

<!-- Corrected the EMPTY Declaration -->

<!ELEMENT Guard EMPTY>

<!ATTLIST Guard

          Name CDATA #REQUIRED

          Expression CDATA #REQUIRED> 

OCTET-STREAM

OCTET-STREAM



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC