[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
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. >>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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]