Re: Core Component Analysis - SWIFT's Comments

[Martin Bryan <mtbryan@sgml.u-net.com>]

Hisanao

> I can draw the class diagram in Japanese using Rational Rose.
> My concern is how to convert the class diagram in Japanese to XML DTD in
> English.
> More precisely, in the phase of BOM, BRV, BTV, several business experts
are
> involved, and they would like to express their view in those models using
> Japanese language. After the phase of BTV, I wonder BSV can be described
in
> Japanese. For the IT expert in Japan can design BSV in Japanese more
easily
> than in English.
> My question is WHEN the class diagram in Japanese can be mapped in English
> version of the class diagram or XML DTD, and HOW.

As far as I can see the conversion of BOM, BRV or BTV information to XML
does not involve the creation XML schemas that can be used to validate XML
messages. Surely what is involved here is to use the Japaense text as the
contents of messages conforming to the schema produced by the BP team

The DTD for these messages is shown at the foot of this message. This leads
to messages of the form:

<?xml version="1.0"?>
<!-- edited with XML Spy v3.0.7 NT (http://www.xmlspy.com) by Cory Casanave
(Data Access Technologies) -->
<!DOCTYPE EbXmlProcessSpecification SYSTEM "ebXmlSpecificationDTD090.dtd">
<EbXmlProcessSpecification>
 <package name="Ordering">
  <document name="QuoteRequest">
    <documentation>
                    This is an example of a minimal order or quote.  For all
document types
                    we assume a built in (global scope) library of types:
                      Integer, String, Text, Float, Decimal, Date, Time,
                      DateTime, Currency, Duration.
                      Other built-in types may be added by core components
                  </documentation>
                  <attribute name="ID" type="String" required="true"/>
                  <attribute name="customerID" type="String"
required="true"/>
                  <attribute name="Items" type="LineItem" multiple="true"/>
  </document>
                <document-set name="QuoteRequestSet">
                  <content name="QuoteRequest" type="QuoteRequest" />
                </document-set>

  <document name="Order" supertype="QuoteRequest">
   <attribute name="total" type="Decimal" required="true"/>
                        <attribute name="creditCard" type="String"
isConfidential="true" />
  </document>
                <document-set name="OrderSet">
                  <content name="Order" type="Order"
isSignatureEntity="true"/>
                </document-set>

<aggregate name="LineItem">
                  <documentation>
                    This is an example of a minimal order line item, used as
an attribute
                    in order and quote.
                  </documentation>
   <attribute name="partID" type="String" required="true"/>
   <attribute name="specialInstructions" type="String"/>
   <attribute name="quantity" type="Float" required="true"/>
   <attribute name="price" type="Decimal" required="false"/>
   <attribute name="picture" type="image"/>
  </aggregate>

For Japanese models the contents of the name attribute will be in Japanese
but otherwise the elements will be identical.

However, I expect your real question is "How, and when, do I create an XML
schema from a UML model that describes the contents of a business message."
As far as I am aware this part of the UML model is not covered by the BP
schema, which does not currently provide for all of the information set
required by the Core Component Metamodel. However there is no significant
difference between the requirements. For example, it would be valid to have
an XML W3C schema element definition of the form:

<element name="LineItem">
   <annotation>
                  <documentation>
                    This is an example of a minimal order line item, used as
an attribute
                    in order and quote.
                  </documentation>
    </annotation>
    <complexType>
     <attribute name="partID" type="string" use="required"/>
     <attribute name="specialInstructions" type="String"/>
     <attribute name="quantity" type="float" use="required"/>
     <attribute name="price" type="decimal"/>
     <attribute name="picture" type="image"/>
   <complexType>
  </element>

However, this would require messages whose form was:

<LineItem partID="abc" specialInstructions="" quantity="3" price="12.00"
picture="*"/>

Such a form of message element will not be very easy to process using XSL.
It will also not be extensible. For example, there are no qualifiers
indication units of measure or currency, both of which need to be known
prior to processing.

Note that once again, Japanese characters can be used in place of the
element and attribute names and values at any point in this scenario without
changing the English names of the defining elements.

A better model would require a structured result for the model, such as:

<LineItem>
   <partID>abc</PartID>
   <quantity units="gross">3</quantity>
   <price currency="GBP">12.00</quantity>
</LineItem>

To do this you would have to convert the example given above to the form:

<element name="LineItem">
   <annotation>
                  <documentation>
                    This is an example of a minimal order line item, used as
an attribute
                    in order and quote.
                  </documentation>
   <annotation>
      <complexType>
      <sequence>
         <attribute name="partID" type="string"/>
         <element name="specialInstructions" type="String" minOccurs="0"/>
         <element name="quantity" type="float">
            <complexType>
                <attribute name="units" type="string"/>
                 <!-- I've deliberately simplified the datatype of this
attribute to simplify the example.
                        In practice you would use an enumerated list of
permitted units. -->
            </complexType>
          </element>
         <element name="price" type="decimal" minOccurs="0">
            <complexType>
                <attribute name="currency" type="string"/>
                 <!-- I've deliberately simplified the datatype of this
attribute to simplify the example.
                        In practice you would use an enumerated list of
permitted units. -->
            </complexType>
         </element>
         <element name="picture" type="image" minOccurs="0"/>
      </sequence>
      </complexType>
</element>

Whilst this works for "simple" models, it does not work for complex ones in
which other constraints need to be expressed because the BP model does not
allow for the expression of a significant range of constraints of the type
required by Core Components.

I hope the above helps to allay your fears. As Japanese characters are
permitted in XML attribute values any of these versions can be used in
conjunction with models expressed in Japanese.

Martin Bryan

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v3.0.7 NT (http://www.xmlspy.com) by Cheryl
Casanave (Data Access Technologies) -->
<!ELEMENT EbXmlProcessSpecification ((package | business-transaction |
binary-collaboration | multi-party-collaboration)*)>
<!ELEMENT package ((documentation | package | business-transaction |
binary-collaboration | aggregate | document | document-set | unstructured |
multi-party-collaboration)*)>
<!ATTLIST package
 name CDATA #REQUIRED
>
<!ELEMENT aggregate (documentation?, attribute*, documentation?)>
<!ATTLIST aggregate
 name CDATA #REQUIRED
 supertype CDATA #IMPLIED
>
<!ELEMENT document (documentation?, attribute*, documentation?)>
<!ATTLIST document
 name CDATA #REQUIRED
 supertype CDATA #IMPLIED
>
<!ELEMENT attribute (documentation?)>
<!ATTLIST attribute
 name CDATA #REQUIRED
 type CDATA #REQUIRED
 required (true | false) "false"
 multiple (true | false) "false"
 isLink (true | false) "false"
 isConfidential (true | false) "false"
 isTamperProof (true | false) "false"
 isAuthenticated (true | false) "false"
 isSecureEntity (true | false) "false"
 isSignatureEntity (true | false) "false"
>
<!ELEMENT unstructured (documentation?)>
<!ATTLIST unstructured
 name CDATA #REQUIRED
 mimeType CDATA #IMPLIED
>
<!ELEMENT documentation ANY>
<!ELEMENT document-set (documentation?, content*, documentation?)>
<!ATTLIST document-set
 name CDATA #REQUIRED
>
<!ELEMENT content (documentation?)>
<!ATTLIST content
 name CDATA #REQUIRED
 type CDATA #REQUIRED
 required (true | false) "false"
 isLink (true | false) "false"
 isConfidential (true | false) "false"
 isTamperProof (true | false) "false"
 isAuthenticated (true | false) "false"
 isSecureEntity (true | false) "false"
 isSignatureEntity (true | false) "false"
>
<!ELEMENT business-transaction (documentation?, request, response*,
security?, timing*, documentation?)>
<!ATTLIST business-transaction
 name CDATA #REQUIRED
>
<!ELEMENT request (documentation?)>
<!ATTLIST request
 type CDATA #REQUIRED
>
<!ELEMENT response (documentation?)>
<!ATTLIST response
 type CDATA #REQUIRED
 status (success | failure) "success"
>
<!ELEMENT security (documentation?)>
<!ATTLIST security
 isNonReputiationReceiptRequired (true | false) #IMPLIED
 isIntelligibleCheckRequired (true | false) #IMPLIED
 isAuthorizationRequired (true | false) #IMPLIED
 isSecureTransportRequired (true | false) #IMPLIED
 isNonRepudiationRequired (true | false) #IMPLIED
 isNonRepudiationReceiptRequired (true | false) #IMPLIED
>
<!ELEMENT binary-collaboration ((documentation |
business-transaction-activity | collaboration-activity | sync-state | start
| transition | success | failure)*)>
<!ATTLIST binary-collaboration
 name CDATA #REQUIRED
 initiator CDATA #REQUIRED
 responder CDATA #REQUIRED
>
<!ELEMENT timing (documentation?)>
<!ATTLIST timing
 timeToAcknowledge CDATA #IMPLIED
 timeToAcknowledgeReceipt CDATA #IMPLIED
 timeToPerform CDATA #IMPLIED
 timeUnit (milliseconds | seconds | minutes | hours | days | weeks | months
| years) "minutes"
>
<!ELEMENT collaboration-activity (documentation?)>
<!ATTLIST collaboration-activity
 name CDATA #REQUIRED
 type CDATA #IMPLIED
 from CDATA #REQUIRED
 to CDATA #REQUIRED
>
<!ELEMENT sync-state (documentation?)>
<!ATTLIST sync-state
 name CDATA #REQUIRED
>
<!ELEMENT business-transaction-activity (documentation?)>
<!ATTLIST business-transaction-activity
 name CDATA #REQUIRED
 type CDATA #IMPLIED
 from CDATA #REQUIRED
 to CDATA #REQUIRED
>
<!ELEMENT transition (documentation?)>
<!ATTLIST transition
 to CDATA #REQUIRED
 guard CDATA #IMPLIED
 condition (success | failure | technical-failure | business-failure | any)
"any"
 from CDATA #REQUIRED
>
<!ELEMENT success (documentation?)>
<!ATTLIST success
 from CDATA #REQUIRED
 guard CDATA #IMPLIED
        condition (success | failure | technical-failure | business-failure
| any) "any"
>
<!ELEMENT failure (documentation?)>
<!ATTLIST failure
 from CDATA #REQUIRED
 guard CDATA #IMPLIED
        condition (success | failure | technical-failure | business-failure
| any) "any"
>
<!ELEMENT start (documentation?)>
<!ATTLIST start
 to CDATA #REQUIRED
>
<!ELEMENT multi-party-collaboration (documentation?, business-partner-role+,
documentation?)>
<!ATTLIST multi-party-collaboration
 name CDATA #REQUIRED
>
<!ELEMENT business-partner-role (documentation?, performs+, documentation?)>
<!ATTLIST business-partner-role
 name CDATA #REQUIRED
>
<!ELEMENT performs (documentation?)>
<!ATTLIST performs
 service CDATA #REQUIRED
 role CDATA #REQUIRED
>