[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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(); ... 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]