Anne,
I'd interject here also - that the OASIS CAM work can provide a standards-based way of tackling this.
Right now we support any modelling tool that can write out their UML components as an XSD schema. ERwin modeller is one such tool.
Then that XSD schema is converted automatically into spreadsheets and XML dictionaries of components, along with NDR evaluation checks and data typing consistency checking.
But the really powerful piece is then what this enables you to do. Create blueprints of message exchange templates using the OASIS CAM template format - using the component definitions from the XML dictionary.
The expander tool then runs the blueprint, expanding the components from the dictionary - and creates the exchange XSD schema for you.
Why is this so important? With UBL approach you end up with mega-schema that are unwieldy and expensive to implement and support. With the blueprint approach - it allows people to create tailored subset schema on the fly - while ensuring consistency through the dictionary. I believe EMIX applications are fundamentally going to be about discreet small message packets in context to their process needs - and hence the blueprint/dictionary approach offers the agility needed.
BTW - this approach is also fully compatible with NIEM and all this tooling is available as open source.
Also - the OASIS SET TC is working in this area too - and the OASIS CAM team is coordinating efforts there.
I'm just finishing up a set of PPT slides on blueprints and dictionaries - that goes into more details - so will post that shortly.
Thanks, DW
-------- Original Message --------
Subject: [emix] modeling / tools example
From: Anne Hendry <ahendry@pacbell.net>
Date: Thu, January 28, 2010 4:45 am
To: emix@lists.oasis-open.org
Hi,
A bit long with the diagram, but since we are coming up on the tools meeting, and modeling is in the air, I thought it might be of some interest to see how another TC (ubl) organized its development process, from modeling to schema generation,. This is a diagram for ubl 1.0 model-to-schema process.
(taken from http://docs.oasis-open.org/ubl/cd-UBL-1.0/, Appendix B, Figure B-1)
This shows the relationship of the various work artifacts. The initial component (reference) models were for conceptualization purposes, with the spreadsheet models then assembled by hand. A customized tool applied NDRs to the spreadsheet models to create schema. Once we had the schema there was a tool (hyperModel, http://xmlmodeling.com/) that created UML diagrams from the schema.
As the standard has evolved the process of transforming from spreadsheets to schema has also evolved, but overall the basics remain the same. We almost eliminated the spreadsheets for modeling but could find nothing better in terms of ubiquitous availability and familiarity (the best lowest common denominator, enabling contributions from a broader spectrum of potential users/contributors) and they were generally easy to generate, manipulate, reproduce, share, etc., with no additional ramp-up time. Now, when we get groups wanting to add to the standard, the acceptance criteria is that they deliver the vetted (aligned) content to this spreadsheet format, which then can be automatically transformed into schema.
Here is a link to one of the spreadsheets of the "spreadsheet assembly model" step shown above: http://docs.oasis-open.org/ubl/cd-UBL-1.0/mod/common/UBL-Reusable-1.0.xls .
This one contains the library of common elements (entities) that were 'common' to all the procurement documents being created.
Most of the column names reflect terminology from ISO 11179 Part 1 http://metadata-stds.org/11179-1/ISO-IEC_11179-1_1999_IS_E.pdf .
which is supported by the NDRs and/or CCTS terminology
http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf .
ISO 11179 is the basis for many data models and data registries, for instance, http://iaspub.epa.gov/sor_internet/registry/datareg/home/overview/home.do
Most columns have an explanatory note popup in the upper right corner of the column header. Some are auto-generated, like the UBL name, using macros. Column 'O' shows cardinality -- required or not, one or many. The Definitions ended up being the basis of an IDD that is now used to localize the standard into a growing number of languages.
One of the schemas created from the above spreadsheet can be seen at
http://docs.oasis-open.org/ubl/cd-UBL-1.0/xsd/common/UBL-CommonAggregateComponents-1.0.xsd
There are many ways to get from here to there, of course, but we found this overall model worked for this particular tc.
Regards,
-Anne
