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

[Duane Nickull <dnickull@adobe.com>]

Clarification:

This was in response to Bruno's email, not Mark's.

Duane

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