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

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

Hi,

my responses to Duane are quoted ***.





dnickull@adobe.com on 04/08/2004 20:10:22

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


"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

<Foo bar="1" bah="2" />

That *seems* all fine an dandy.

The problem is that programmers have to write very specific handler code
to read such values.  In java like this:

//assume use of JDOM ;-)

Attribute attribute1 = current.getChild("Foo").getAttributeValue("bar");
Attribute attribute2 = current.getChild("Foo").getAttributeValue("bah");
String myString = attribute1.toString();
...

***
*** I was not speaking of Java code generation. My point was just to say
that
*** UML and XML has some commonalities and that "meta-modeling" (we may
forget
*** for the moment one possible solution which is "UML meta-modeling") may
help
*** to go from an UML specification to an XML specification and the
reverse.
*** You may also think that the "seamless" is too strong ;-) I only meant
*** that the translation may be supported by tools and not manually.
***

Since the UML is often several layers deep, the "current" token, is
subject to radical change if the hierarchy changes.  This is very
frustrating for any developer to constantly have to re-code their
classes in a grand tense to reflect minor changes in the UML.  Changing
UML does not require the same discipline as re-writing several classes
of code.  (let the flames begin ;-)

There is simply no elegant way to prepare for this with automated
transformations (aside form declaring some JDO's as constants to save
some grief).

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

But this creates problems for managibility over time.  We cannot be so
arrogant and to think we have thought of everything today. People will
need to extend and add to our work over time.  That is the nature of
standards.  If we create a schema and perform validating parses, then
add another mandatory context element, it may break existing context
declaration instances, since they will not have that element.  Likewise,
if we add another nesting of elements, developers will have to hunt
through their code to add in corresponding lines in order to reflect the
changes.  One extra box in a UML Class diagram = many headaches for
hundreds of developers.

A better way to write it is to 'think" about future developers/users and
write XML in a format so other tokens can be added without breaking
forwards or backwards compatibility.

<Contexts>
    <Context  name="Geopolitical" qualifier="ISO-3166" value="CA-on" />
    <Context name="myAddedContext" qualifier="whatever"
value="itsNotImportantToOthers" />
...

The code to read this is simple.  One class supplements the parser by
simply grabbing the Context@value, then passing it to the appropriate
handler class.  When someone adds another one, it does not break
existing implementations.

We have to start thinking of this IMO.

My $0.02 CAD worth.

Duane Nickull

--
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com


***
*** I understand your view and I probably share some of your arguments...
*** but the fact is that the CCTS is based on UML and UBL on XML.
*** One way to keep the specifications aligned is to use human expertise.
*** I was just wondering if there was another way...
***
*** Regards,
*** Bruno