Authoring XML Schemas for use with EMF

This article focuses on authoring and using XML Schemas for the purpose of generating an EMF model.

Introduction

An EMF Model (files of type *.genmodel) is the hub for importing/exporting other metamodel formats, linking to other EMF models, and generating implementation code. Out-of-the-box, EMF can import XML Schema Definitions (XSDs) into Ecore Models (files of type *.ecore). Similarly, EMF can export Ecore Models to XSDs. But without some additional information, EMF uses a default set of transformations that rarely yields the desired results.

Luckily, both Ecore models and XML Schemas have support for annotations. Annotations can be almost anything, but for this discussion, annotations will serve two main purposes:

• Provide additional information when transforming one metamodel to another
• Provide additional information on how to serialize/deserialize your model objects

EMF supports transformations in both directions (to and from XSDs). Currently, if you start with an Ecore model, round-tripping to XSD and back to Ecore should be lossless. However, Ecore supports some structures that have no XSD equivalent, such as multiple inheritance. Information will be lost in such cases. Also, if you start with an XSD, not all of the information will be captured in the Ecore model. Therefore, XSD->Ecore->XSD is not a recommended practice as of the Europa release.

This article will focus only on authoring and annotating XSDs, and importing them into Ecore models. However, it is often a useful learning tool to model certain structures first in Ecore, and then export to see the XSD equivalent.

How it Works

1. An EMF Model is created and associated with one or more XSDs

1. When the Wizard finishes, the conversion process creates *.ecore files

1. At this point, EMF will not read your XSDs again. All information needed by EMF has been captured in the following locations:

1. Ecore Models

   Schemas become Packages; Simple/Complex Types become EClasses, EDataTypes, and EEnums; Elements and Attributes become EStructuralFeatures

1. Annotations in your Ecore Models

   Ecore annotations are added in lots of places to capture the way your model should be serialized/deserialized. These annotations are what enable EMF to read and write XML documents that don't conform to EMF's default serialization format.

1. A Helper EClass named "DocumentRoot"

   In certain cases, EMF must create a DocumentRoot class to store additional information.

1. Helper EStructuralFeatures, such as feature maps with the suffix "group"

   To handle XSD features like substitution groups, the substitution rule to be used when writing must be known. To handle these cases, your Class' EReferences don't hold onto the actual content, but are instead derived from these "group" references which contains keys in addition to the actual referenced object.

1. Your EMF Model

   References to the schemas you imported are kept so that you can invoke a reload later. Generations options are configured the first time with different defaults, under the assumption that you'll be reading and writing to XML files.

Using Substitution Groups

--Hudsonr.us.ibm.com 14:26, 12 June 2007 (EDT)