Réf. : Re: [ubl-dev] RE: UML meta-modeling of UN/CEFACT Core Components

["Bruno TRAVERSON" <bruno.traverson@edf.fr>]

Hello,

My responses to Chin are quoted ***.





cheekai@softml.net on 05/08/2004 08:01:35

Pour : Bruno TRAVERSON/IMA/DER/EDFGDF/FR@EDFGDF, dnickull@adobe.com
cc :   ubl-dev@lists.oasis-open.org
Objet :     Re: [ubl-dev] RE: UML meta-modeling of UN/CEFACT Core
       Components


On Wed, 4 Aug 2004, Duane Nickull wrote:

>>"UML meta-modeling may be a good solution to seamlessly translate the
>>UML specification into an XML specification."
>>
>>I am skeptical.  I have problems with this statement since such
>>methodologies as XMI et al ignore the problems faced by programmers.  If
>>you simply make a UML class with a name of Foo and attributes bar and
>>bah into

I tend to share Duane's skepticism, more on the basis that using
UML modeling, a data model designer will have to grapple with both
(a) business data requirements  and  (b) UML-imposed design constraints
at the same time.  While this is true whichever way the data model
designer chooses to serialize his/her data model, it is practical
to have as minimal a constraint imposed by (b) as possible, leaving
the data model designer room, time and space to focus on (a).

Many people intially (or even now) question UBL's use of spreadsheets
to represent data models.  But this has really nothing to do with
choosing particular technology, vendor or product over another, but
more to do with the simplicity of editing on a 2x2 table of cells.
There's low barrier (if any) to understand the table of cells since
most people are familiar with tables.  The equivalent situation in
UML will be that people who wish to understand the data model must
first learn UML and all its syntax even before the first UBL
data type can be understood.  Imagine requiring SMEs to hire UML
consultants first before they can design their own schemas...

It may be that UML modeling is useful in certain circumstances or
specific environment, in which case it is certainly a good candidate
for that specific scope.  But to generalize that into the quoted
statement may tend to be harder to accept.

***
*** from a practical point of view, I think you are right. Spreadsheets
*** are probably the best formalism for "common" humans ;-)
*** but, from a standardization point of view, we are faced to the fact
that
*** UN/CEFACT standard is expressed in UML and OASIS standard has chosen
*** XML. What kind of solutions do you suggest to keep the specifications
*** aligned? I was suggesting meta-modeling. To generalize a little, it
should
*** be nice to have tools that translate in a bidirectional way UML, XML
and
*** spreadsheet specifications not only at the instance level but also at
the
*** model level.
***
*** Regards,
*** Bruno


>>I favor an approach whereby we use thinking to create XML that will
>>protect investments into existing code by attempting to be backwards
>>compatible, at the same time accounting for forwards compatibility.  An
>>example of this is the "contexts" of CCTS.  It would be tempting to
>>write the contexts as such:
>>
>><Contexts>
>>    <GeopoliticalContext>
>>            <Value> Canada</Value>
>>    </GeopoliticalContext>
>>    <SomeOtherContext>
>>             <Value>1234</Value>
>>    </SomeOtherContext>
>>...

I tend to think that this pushes the standardization from
schema standardization to run-time data value standardization.
For instance, the data values in your example <Contexts> above
exist in the instance documents, not in schema space.  Depending
on the typing of <Value>s, many assumptions will have to be
made when interpreting the data found within <Value>s.  If they
are not enumerated values, then processors will need dictionary-
directed function calls to act or react on what is found within
the <Value>s.   The kind of standardization needed can be rather
immense.  And even assuming such has been done, you've correctly
menioned that there'll be data management problems over time
when new values are added to the permitted data within <Value>s.

It is not impossible to do, but given the large number of
different circumstances that <Contexts> need to handle (and
perhaps squared or cubed because the sender has one set of
contexts and the receipient will have another set, or a preferred
context indicated by sender that a receipient ought to have, etc),
the amount of standardization work might be quite a challenge.  Also,
document-validity issues must also be addressed, such as when the
rest of the non-<Contexts> document validates properly, but the
data found within <Contexts> could not be handled by receipient,
and many other combinations of exception handlings.  So I'm
also doubtful about the feasibility of carrying dynamic data for
the purpose of complimenting data models.

However, using the same mechanism for holding generic header
to contain system meta data (data generated by sender's processing
systems and consumed by receipient's processing systems) would be
a different case. But that's for another discussion.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/