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

[Duane Nickull <dnickull@adobe.com>]

"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();
...

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