[October 10, 2001] The UML to XML Design Rules Project was approved as an activity under the UN/CEFACT Electronic Business Transition Working Group. The purpose of the UML2XML project is "to produce a set of formal syntax production rules, describing in a very detailed and strict way how to convert standardized business messages, which are defined in UMM-compliant UML class diagrams, into physical XML representations. The project deliverables include a Technical Specification describing the set of formal design rules needed to convert the UML class diagram representing a standardized business message into a physical XML representation. This Technical Specification will also include specifications for the UML representation of a standardized business message... The project team will consist of a group of experts who have broad knowledge in the area of Electronic Business (ebXML, UN/EDIFACT, and national EDI/eBusiness), XML technologies, XML implementation, use of UML and technical specification development. Each UN/CEFACT head of delegation may designate one or more experts to the project team. In doing so, they may delegate this task to one or more organizations, which may be national, regional or international. Experts are expected to contribute to the work based solely on their expertise..." [description 2001-10-10]

Early contributions toward the draft requirements were presented by SWIFT, OMG, Bolero, and others. Examples:

David Frankel submitted OMG's XMI2: "As a contribution to the discussion about ebXML's UML-XML mapping rules, I submit for consideration the XMI Schema specification, which was approved by the OMG Architecture Board last month and is in the final stages of ratification by the OMG membership as a whole. It defines MOF-XML Schema mapping rules, MOF being essentially a subset of the part of UML that supports class modeling. OMG owns the UML, MOF, and XMI standards. This new specification has the following improvements over earlier versions of XMI: (1) Support for XML Schema (2) The mapping is now highly parameterized, giving users much more flexibility to specify how the rules should work. For example, in some earlier ebXML discussions there was a debate about whether a class attribute should map to an ELEMENT or to something in the ATTLIST for the ELEMENT that corresponds to the class. XMI Schema defines a parameter that allows you to specify which approach to use. There are quite a few additional parameters. Refer to section 4.10 for the details of the tailoring parameters. (3) A reverse mapping is defined. (4) A formal MOF metamodel of XML schema is defined..."

Draft XMI2 (June 12, 2001). "XML Metadata Interchange (XMI). Response to the RFP ad/2000-01-04 for XMI Production of XML Schema." Joint Revised Submission by International Business Machines (IBM), Unisys, and SofTeam. OMG Document ad/2001-06-12. June 18, 20001. 164 pages. Send comments on this submission to xmi-rtf@omg.org. All questions about the submission should be directed to Stephen A. Brodsky, Ph.D., International Business Machines Corporation, +1 (408) 463-5659. ['This submission is an extension to the XMI 1.1 specification, ad/99-10-02.'] From the Introduction: "XMI is a widely used interchange format for sharing objects using XML. Sharing objects in XML is a comprehensive solution that build on sharing data with XML. XMI is applicable to a wide variety of objects: analysis (UML), software (Java, C++), components (EJB, IDL, Corba Component Model), and databases (CWM). Over 30 companies have XMI implementations. XMI defines many of the important aspects involved in describing objects in XML: (1) The representation of objects in terms of XML elements and attributes is the foundation. (2) Since objects are typically interconnected, XMI includes standard mechanisms to link objects within the same file or across files. (3) Object identity allows objects to be referenced from other objects in terms of IDs and UUIDs. (4) The versioning of objects and their definitions is handled by the XMI model. (5) Validation of XMI documents using DTDs and Schemas. XMI describes solutions to the above issues by specifying EBNF production rules to create XML documents, DTDs, and Schemas that share objects consistently. XMI 1.1 defines production two kinds of production rules for sharing objects with XML: [A] Production of XML DTDs starting from an object model, and [B] Production of XML documents starting from objects. In addition to generating XMI 1.1 compliant Schemas, we have produced a mapping for how XMI looks if we used new features in Schemas that are not available in DTDs. Based on these experiences, we can recommend a course for XMI as well as suggest improvements to XML Schema. This new form, called XMI 2.0, is a successor to the XMI 1.1 form. With the recent work by the W3C in XML Schemas, a more comprehensive form of XML document validator, this submission adds these production rules: (1) Production of XML Schemas starting from an object model; (2) Production of XML Documents compatible with XML Schemas; (3) Reverse engineering from XML to an object model. MOF is the foundation technology for describing object models, which cover the wide range of object domains: analysis (UML), software (Java, C++), components (EJB, IDL, Corba Component Model), and databases (CWM). XMI is applicable to all levels of objects and metaobjects. Although this document focuses on MOF metaobjects, general objects may be serialized and interchanged with XMI. The term 'XML document' in this specification is equivalent to a general stream of XML data..." Also in PostScript and .ZIP/PDF format; see the document listing. [cache PDF]

"SWIFTStandards XML Design Rules." Technical Specification. Version 2.3 5. September 5, 2001. 52 pages. Submitted [October 6, 2001] by Frank Vandamme to the UN/CEFACT eBTWG Open Process. ['Please find attached the SWIFT initial contribution on UML to XML design rules...'] From the document Introduction: "XML is a technical standard defined by W3C (the World Wide Web Consortium) and leaves a lot of freedom for the exact way it is used in a particular application. Therefore, merely stating that XML is used is not sufficient, one must also explain how it will be used. The use of XML is part of the overall approach for the development of SWIFTStandards. This development focuses on the correct definition of a business standard using modelling techniques. The resulting business standard is captured in UML (Unified Modelling Language 2 ) and is stored in an electronic repository, the "SWIFTStandards Repository" . Business messages are defined in UML class diagrams and XML is then used as a physical representation (i.e., the syntax) of the defined business messages. A set of XML design rules, called SWIFTStandards XML, define in a very detailed and strict way how this physical XML representation is derived from the business message in the UML class diagram. This document explains these XML design rules. The document does not explain how a message should be created in UML. It explains, once a message is created in UML, how it will be mapped into XML. [General mapping rules:] Mapping rules from UML to SWIFTStandards XML are governed by the following design choices: (1) SWIFTStandards XML representation to be as structured as possible: [Business information is expressed as XML elements/values. Metadata information is expressed as XML attributes. XML attributes are not to be conveyed 'on the wire' in the XML instance, unless required to remove ambiguity. (2) The current work is based on W3C's Recommendation of May, 2001. (3) The names used in SWIFTStandards XML are the XML names or, when absent, the UML names. (4) SWIFTStandards XML elements are derived from the UML representation of a business message. They can only be derived from UML-classes, UML-roles or UML-attributes. (5) Each SWIFTStandards XML element must be traceable to the corresponding UML model element. (6) Currently SWIFTStandards XML only runtime Schemas are generated. Runtime schemas only contains information required to validate XML instances. No documentation nore implementation information (e.g., elementID, version, etc.) is mentioned. ... SWIFTStandards XMLTag is assigned according to following rules: [1] For a SWIFTStandards XML element derived from a class if that class contains the stereotype <<message>>: the XML name of the class or by default the name of the class. [2] For a SWIFTStandards XML element derived from a role: The XML name of the role or by default the name of the role. If no rolename is specified in the UML model, the name (XML name or name by default) of the class which is at the end of the aggregation. [3] For a SWIFTStandards XML element derived from an attribute: (3) The XML name of the attribute or by default the name of the attribute. [Note: Classes that don't contain the stereotype <<message>> do not have a corresponding XML element.]..."

"Bolero Document Modeling Conventions." By Phil Goatly (Bolero). October 2001. 31 pages. Submitted [October 5, 2001] by Phil Goatly to the UN/CEFACT eBTWG Open Process. "The following submission documents the modeling conventions used by Bolero in phase one of UML to XML conversion. They are submitted to the group in the knowledge that somethings could be done better. Currently we are working on phase 2 which involves schemas and changes to the conventions, as such, this document may be regarded as a prototype - but even prototypes have their uses. Many of the conventions used in this document will be changed in phase 2. The submission is submitted in the hope that it will stimulate discussion, and allow us to submit our thoughts on the future of the important topic of UML to XML production rules... BoleroXML makes a distinction between a message and a document. A document contains only data, whereas a message contains data and involves a sender and one or many receivers. This report is only concerned with data modelling for documents. The interface between this document model and the message model is construed via the parties who send the messages and by the data which they send. The document model is the 'data model' and the message model is the 'data flow model'. ... BoleroXML's key objective is for the document models to have no dependency on the technology solution used for implementation. This safeguards the use of document definitions against any impact from changing technology where changes can be addressed without having to redefine the underlying business requirements. In support of this objective, BoleroXML has chosen to model the requirements for these document definitions in Unified Modelling Language (UML), with a set of rules and conventions described in this document. UML was selected to support BoleroXML's vision of being able to house all definitions in a single repository, ensuring unambiguous data definitions and consistency across all documents. The goal is to be able to extract the document definition, by means of an automated conversion, from UML to any desired implementation tool.." [Note with submission to eBTWG: "Please find attached a submission from Bolero. This is a document showing our Phase one UML to XML documentation. It may be regarded as a prototype since we have learnt so much for producing 70+ documents for international trade using modeling conventions and the generator over the last 2 years. see our website for details We are now well into phase 2 of rationalisation of our modeling techniques and conventions-schemas - normalization etc. with many changes taking into account our 20/20 vision in hindsight and to correct thos things we which we got blatantly wrong... we are producing a normalised model of the international trade domain. From that every 'Trade Document" will be a view.i.e. Not all links will be seen on every document neither will every 'field' be seen. We have produced s/w to import the 'normalised database' into UML. We will then produce diagrams of 'documents' and our generator will work from these diagrams on a WYSIWYG basis. Our experience hase been to hide the complexities og UML from the BA and to generate DTDs etc. from the simple UML..."] See also the original .DOC/Word version and BoleroXML.

"Bolero Comments on [SWIFT/UML] Modeling." Document posted to the eBTWG mailing list. October 10, 2001. "The guiding principles for boleroXML tools and methodologies are: (1) Compliance with standard UML; (2) Compliance with standard XML; (3) Compliance with ebXML where relevant; (4) Technology independence; (5) Maximum automatic generation of computer artifacts; (6) Adaptability to change; (7) Adaptability to multiple and differing industry requirements... We have endeavoured to keep any extensions to the UML language, by use of stereotypes, to a minimum. We firmly believe that, if a large number of extensions is required to the UML modelling language to achieve our ends, then either we are using the wrong modelling language, or we are in some way misusing UML. Currently we have at most 4-5 stereotype extensions and have not needed more. This has been in no way constricting on our modeling, since we have produced 70+ complex electronic documents, using as a base, in excess of 1500 classes. We have also attempted to keep all reference to any implementation of UML out of the model/s. Any explicit reference to say XML or ODBC , C++, Java etc. in the data model must be avoided. This is because the data model may be used in a number of ways. For instance, any information that is required by a program generator should be encapsulated in an area of the model devoted to the particular implementation concerned e.g., by using UML tags devoted to a particular generation tool. We speak out of hard experience, since we made a mistake of not doing this at one point and do not want to suffer from similar problems in the future..."

Telecommunications Markup Language. "tML Guidelines for Mapping UML Notation to XML Schemas and Vice Versa." Telecommunications Markup Language. PROJECT T1M1-26. Document T1M1/2001-100R3. Submitted by Raymond E. Reeves. "This technical proposed standard provides guidelines for defining Telecommunications Markup Language (tML) Schemas based on Unified Modeling Language (UML) notation design models and vice versa. This work is proposed to help TMN paradigm independent design models to be mapped with little or no effort to an Extensible Markup Language (XML) implementation. Efforts underway in the ANSI T1 and ITU-T bodies to create implementation independent models will take advantage of this recommendation." From followup comments: "...the draft standard prepared by T1M1 tries to address the UML and XML Schema mapping from a bi-directional standpoint. Though the document is organized from a UML viewpoint (UML2XML view?, i.e., model management view, static view, etc.), it purports to provide all necessary rules for doing round-trip engineering. Next version (release 4) will describe, in a more explicit fashion than the up to now implied, 'UML Profile for XML Schemas' used throughout the document. The importance of this effort within T1M1 and ITU-T (because it is an ITU-T work item) lies in the fact that many other T1M1 (and, why not?, ITU-T) XML-ization efforts (e.g., Service Ordering, Trouble Administration, DSL Service Provisioning, etc.) use a model-driven approach where a UML model is prepared from which a t/XML Schema is prepared following the guidelines stated by the T1M1 UML to XML Schemas, and vice versa, draft standard..." See also the note by Dave Carlson: "I've taken a quick read through your T1M1 mapping spec and it is very similar to my approach. My default mapping is aligned with the schema production rules in the XMI spec, but with a few additions. For example, XMI requires a role name on every navigable association end. And the schema includes a container element for this role, and a content element for the destination class. I've found that many schema designers want to create more compact vocabularies that omit the container element or make the destination class name anonymous. Both of these extensions can be made without modifying the UML conceptual model itself, but specifying preferences in the schema generator. Or by setting properties only on the top-level UML model or packages. So this retains the goal of technology indepencence that has been stated in other messages. I share that goal..." [alt URL, cache]

References:

• UML to XML Design Rules Project Proposal
• [October 19, 2001] eBTWG - Scope and Requirements for UML2XML Design Rules." UN/CEFACT/CSG/eBTWG UML2XML Design Rules project. Preliminary Draft. Revision #1. October 17, 2001. Posted by Frank Vandamme.
• UML2XML - Initial list of requirements (2001-10-09). The second requirement addresses support for W3C Schema features. Produced by EBTWG / UML2XML.
• UN/CEFACT Electronic Business Transition Working Group
• Announcement 2001-09-06: "eBTWG Announces Inaugural Meeting to Advance ebXML Development."
• eBTWG Projects
• Elists for lists.ebtwg.org
• See also: "XML Metadata Interchange (XMI)."