How to cite this paper
Engineering Document Applications — From UML Models
to XML Schemas
Balisage: The Markup Conference 2009
August 11 - 14, 2009
Organization of the paper
In the Engineering Publishing Technology Group, we aim to leverage modeling and other
methods of software engineering for document engineering and electronic publishing.
Particularly, in this paper, we align UML class diagrams, which model persistent data,
XML Schemas, their implementational counterparts that constrain the XML implementation
persistent data as documents. We have felt the need to provide, for the Balisage audience,
the first “real” section of this paper (Models in software engineering)
some background information on the role of and technology for modeling in software
engineering. We continue the paper with a section (Modeling persistent data) on the
modeling of persistent data and schema engineering for XML implementations of persistent
should have in software engineering processes. In the next section (Focus of this
present a management summary of our contributions in this paper.
The next four sections expand on a number of aspects: In the first of these four
(Transforming UML models to XML Schema using XMI), we talk about the ways in which
we can make
use of the XML Metadata Interchange XMI for our purposes. The second (XMI schemas
class diagrams: The XMI mapping) reports on the way that XMI maps UML class diagrams
Schemas. The third (Adapting the XMI mapping to the document setting) talks about
and modifications to the XMI mapping that are required in a document setting. The
final section (Realizing the layer shift using XSLT) introduces our implementation;
particularly, it explains what we call the layer shift, our method that leverages
implemented XMI export of UML modeling tools.
We finish the paper with a section that gives our conclusions and discusses some related
Models in software engineering
In this section, we represent the well-established perspective of the software engineering
discipline to modeling. The state of the art is discussed in many excellent textbooks.
been working with the one by Brügge and Dutoit [BrüggeEtAlsOOSWE] .
Modeling is a pivotal activity in the engineering of software systems. Based on the
principles of abstraction and implementation, and used in evolutionary phases that
stepwise refinements, it is the key method to deal with complexity and change. Models
communication and drive software development processes. Modeling is common practice
particularly in the earlier phases of software development. During requirement analysis,
models support communication between software engineers and domain experts; during
they document design intent to implementors; during implementation, they abstract
syntactic details of programming languages. The long-standing vision of software engineering,
namely to drive the development process by models that are systematically transformed
lower-level models and software artifacts, has more recently found its expression
approach of model-driven architecture. It is a widely acknowledged benefit of model-driven
software development that it enforces uniform coding principles and strategies, leveraging
best practices, and that it reduces error rates. The most striking advantages are:
Coherence between models and their implementations; this may go as far as to proven
Rational and documented transition between models on different levels of refinement,
With the Unified Modeling Language UML, the Object Management Group OMG offers a graphical
notation for defining models. The UML provides several types of diagrams for the modeling
software systems. Software engineering methods such as the Rational Unified Process
based on the UML. They are supported by so-called CASE tools; that is, WYSIWYG editors
create and edit UML diagrams. The more powerful CASE tools allow for code generation
engineering), in pursuit of the vision of model-driven software development. Over
decade, the UML has replaced previous modeling languages in software engineering practice.
Modeling persistent data
Let us turn our attention now to a specific but important aspect of software systems,
persistent data. Traditionally, if data volume and access requirements make custom
unfeasible, data have been persisted in databases, with relational databases claiming
lion's share of the market. Increasingly, XML and XML database management systems
play, the former as a format for persistent data and the latter for management and
the XML data. In particular, XML establishes itself as the data format of choice if
structured irregularly (semi-structured data) of if data are genuine textual
documents [AbiteboulEtAlDataOnTheWeb] .
We pose three requirements for the modeling of persistent data:
Modeling of persistent data must be integrated into system modeling.
Modeling of persistent data must be independent of data implementation technology.
Modeling of persistent data should be amenable to forward engineering.
How do these requirements mesh with the reality of XML modeling?
With schema languages such as DTD, XML Schema, Relax NG and
[vdVlistXMLSchema] , the XML community has developed XML-specific modeling languages that
are supported by XML-specific modeling
[StephensonBestPractices] . Tool support is available in the form of graphical
editors for schema languages, requiring XML domain knowledge from software engineers
Fundamental weaknesses of this approach are that the modeling depends on the schema
technology, that the modeling language is very close to the implementation language
the modeling of documents is separated from and not integrated into the general system
modeling. These deficits persist even if XML modeling tools are integrated as modules
general UML tools, as it is the case, for example, with Altova UModel or HyperModel.
What options do we have if we want to truly integrate schema engineering into software
engineering? In this, we will be guided by proven software engineering procedure.
in software projects persistent data are modeled as UML class diagrams. Historically,
are two main options to implement the data. The first option implements data as objects
specific programming language and then “marshals” the objects into a
custom data format for persistent storage. The second option stores data in a database.
both cases, not only the data but also their models have an implementation counterpart,
in the form of class declarations in a programming language or in the form of a database
schema definition. If we persist data as XML documents, the obvious implementational
counterparts to data models are XML Schemas. Hence, the sound software engineering
to regard XML as a target platform for persistent data and to transform data models
Schemas that constrain the XML-encoded data [PaganoDA] . This puts not only
XML but also XML Schema and other XML schema languages firmly on the side of implementation
Focus of this paper
In this paper we present a method, which we call uml2xsd, to translate conceptual
that, following current software engineering practice, are written as UML class diagrams
XML Schemas, thus aligning UML class diagrams, which model persistent data, with XML
which constrain the XML representation of persistent data as documents. The paper
quintessence of research that the first author did for his diploma
thesis [PaganoDA] under the supervision of the second author.
We base this work on XMI, a method that the Object Management Group (OMG) has defined
models that are written in its modeling language MOF into equivalent XML Schemas.
Due to the
architectural alignment of MOF and UML, MOF models can be considered as specific UML
that represent concepts in the form of class diagrams. Hence, we were able to pattern
after the OMG translation of MOF models in XML Schema, extending it to concepts that
present in UML class diagrams but not in MOF models.
The OMG method is defined on a conceptual level. We are not aware of any tools that
implements this method. Hence, XMI provides a conceptual guideline for uml2xsd, but
no precedence for an implementation.
There is, however, another aspect of XMI that we can build on: The goal of XMI is
facilitate exchange of models as XML documents. The MOF language is used as a language
define metamodels (models whose instances are models), such as the UML metamodel.
method that we have mentioned above, is used to translate such metamodels into specific
Schema documents that are called XMI schemas. Applied to the specific metamodel of
method yields a single XMI schema that constrains XML representations of UML models,
called XMI documents.
Our method uml2xsd leverages the common capability of modern UML tools to export UML
as XMI documents. It transforms an XMI representation of a UML class diagram into
Schema that constrains XML instances of the UML model. It is patterned after transformations
into XML Schema that XMI defines for models in its MOF language, which, due to the
architectural alignment, are closely related to UML class diagrams. Our method achieves
shift from the XML instance layer that XMI supports for model interchange to the XML
layer that supports modeling itself. Being based on XMI as a standardized interchange
for UML models, uml2xsd is independent of specific UML modeling tools or software
methods. Technically, uml2xsd is an XSLT program that operates on XML representations
class diagrams, the XMI documents, and turns them into XML Schemas.
The core idea behind uml2xsd is to generate from UML class diagrams not XML instances,
the XMI way, but XML Schema documents, thus aligning conceptual instances of UML models
XML instances of XML Schema documents. We make use of the XMI support of UML modeling
that we first export UML class diagrams as XMI documents and then translate the results
XSLT into XML Schema documents. The translation rules adapt XMI translation rules
higher level of the so-called MOF metamodel hierarchy, which is enabled by an alignment
between the metamodel hierarchy and UML class diagrams. This “layer shift”, which
we are going
to explain in more detail further on, validates the uml2xsd approach.
In principle, the uml2xsd method should work with XMI data that were exported from
tool. In practice, however, XMI allows for a wide spectrum of variants to represent
artifact in a UML diagram, so we hesitate to claim too much. We have, however, successfully
tested the implementation with a number of UML tools, particularly with Enterprise
and Altova UModel.
At Extreme Markup Languages 2007, the Engineering Publishing Technology Group has
principles, patterns and procedures of translating a conceptual document model in
form of a
simple UML class diagram into an XML Schema document [EPTatEML2007] . In a
contribution [EPTatBalisage2008] at Balisage 2008, we have extended our
investigation to more complex document models that exhibit relationships between classes,
coding relationships on the XML side of documents with XLink and embedding processing
for XLink into XQuery. With appropriate configuration of uml2xsd, we are now able
these translations. We have applied uml2xsd to automatically generate XML Schema documents
from conceptual models of two XML applications, XBlog and XTunes.
We have further evaluated uml2xsd by applying it to the UML metamodel (which is an
instance of MOF and, hence, an UML class diagram); the result is an XML Schema for
UML that is
equivalent to the XMI encoding rules of UML class diagrams.
Transforming UML models to XML Schema using XMI
As we have briefly sketched out above, there already exists a standard for the generation
XML Schemas out of models namely XMI, the XML Metadata Interchange specification.
the OMG has standardized a data format that aims at the interchange of models. The
goal is to
support interoperability of UML modeling tools. There is urgent need for such support
particularly in globally distributed software projects, a number of modeling tools
simultaneously in use. XMI not only supports UML models, but also
MOF [OMGMOFCore] compliant models in general. It defines standards for
the creation of so called XMI schemas, which represent MOF compliant metamodels such
UML metamodel, and XMI documents, which represent the actual models such as UML models;
latter are instances of a metamodel's representation as an XMI schema. Thus XMI enables
validation of models in their XML representations against an arbitrary MOF compliant
Since UML is designed using the MOF and because the UML metamodel itself is an instance
the MOF model [OMGMOF] , XMI can be (and is in most cases) used to exchange
and validate UML models via XMI documents. As the names suggest, XMI documents are
XML documents and XMI schemas are specific XML Schema documents. So when using XMI,
are actually transformed into XML documents, not into XML Schemas! Why that, didn't
above that from the perspective of object persistence, we would expect conceptual
to be transformed into XML Schemas? That's still valid, but XMI was designed to validate
exchange models, and for that purpose it is best to transform models into XML documents;
is, document instances that can be validated against an XML Schema using common XML
Since XMI defines rules for generating XMI schemas (which are special XML Schema documents
we have seen) from MOF compliant metamodels, the question arises whether we can also
rules to generate XMI schemas for conceptual UML models. The answer is yes. Because
architectural alignment of UML and MOF, conceptual UML models (models represented
by UML class
diagrams), are defined using the same concepts as MOF compliant meta
models. [OMGMOFCore] Thus, we are able to interpret UML class diagrams
as MOF compliant metamodels from an XMI point of view, which allows us to use the
defined by the XMI specification to generate XMI schemas from conceptual models. We
process, which effectively creates an XMI schema from a conceptual UML model encoded
in an XMI
document, layer shift. The attached figure illustrates the model-instance
relationships, the mappings and the levels on which the models and their instances
XMI schemas from UML class diagrams: The XMI mapping
In our research [PaganoDA] we have surveyed the XMI specification
regarding its possibilities to map conceptual models to certain XML Schema documents,
the XMI schemas. Our focus was to determine whether XMI allows a sound transformation
models for XML applications into XML Schema documents that represent their document
This question arises from the fact that XMI was designed with a completely different
namely the standardization of the interchange process of MOF compliant models.
First of all, although XMI targets MOF compliant models in general, the transformation
conceptual models in the form of UML class diagrams is possible due to architectural
in the form of the common infrastructure of UML and
MOF [OMGUMLInfrastructure] . The OMG defines how to generate
MOF-compliant models [OMGXMIMapping] as a set of predefined rules that can
also be configured for special purposes. This configuration comprises the use of a
set of so-called tagged values in the MOF models that are to be transformed. These
values are also defined in the XMI specification. In the following, we provide a short
overview of the transformation rules specified in the XMI specification.
The general structure of an XMI schema is how we would expect an XML Schema document
like, including namespace declarations and imports of XMI specific XML Schema types.
default, XMI software generates only one XMI schema for a complete UML model, without
a target namespace therein. But the annotation of UML packages with an XML namespace
in the generation of one XMI schema per UML package, each using the specified XML
target namespace. This allows for the transformation of equally named UML elements
different packages, what would otherwise be impossible.
For UML packages XMI specifies the use of elements with locally defined complex types.
complex type is then made up of a choice of the UML elements contained in the according
package, which are referenced in the choice. Similarly, UML classes are transformed
element declarations and complex types, but in contrast to packages, the elements'
declared globally. The elements and their types are put into the target namespace
containing package. The content model of both packages and classes is very generous
is realized as an XML Schema choice construct with open bounds, and thus hiding any
multiplicity by default. But this representation can be changed using tagged values
enforce the use of the multiplicities as specified in the model.
UML attributes are transformed into element declarations, which are directly put into
choice in the definition of the complex type that represents the containing class.
Additionally, an attribute declaration is appended for UML attributes with simple
and a multiplicity of at most one. However, the type of declaration can be influenced
tagged values, for example to persist the order of the elements using sequences instead
choices. Every complex type by default references an additional attribute predefined
XMI specific XML Schema types that is used as an identifier. However, by annotating
attribute with a certain tagged value, this attribute can be declared as the identifier
UML associations are defined using association ends that reside in the classes that
participate in the association. XMI generates both an element declaration and an attribute
declaration for each association end contained in a class. As the association end's
uses the predefined type “Any” that allows arbitrary content for the element. This
instantiation of classes in the content of other classes and therefore enables the
construction of redundant but valid XML documents. We consider this redundancy a weak
the XMI specification.
For inheritance, a specific type of association, XMI uses
“copy-down-inheritance” [OMGXMIMapping] by default: The subclass is
transformed into a complex type under the rules, but first the properties of all base
are copied. Then these are extended or replaced by the properties defined in the subclass
itself. The copy-down-inheritance is only a workaround for the realization of multiple
inheritance that XML Schema does not support natively. In the sense of the term it
really an inheritance mechanism, as the relation between base class and subclass gets
during the transformation. If a UML model only uses simple inheritance, the use of
XML Schema inheritance mechanism can be enforced by using the proper tagged values.
contrast to the way associations are represented, the use of copy-down-inheritance
seen as a drawback of XMI, because it is XML Schema that lacks the concept of multiple
Adapting the XMI mapping to the document setting
Clearly the XMI specification was designed with the goal to facilitate the interchange
validation of models, not to represent conceptual models in the form of XML Schema
But most of the rules that transform UML model concepts into XML Schema concepts are
from the perspective of a conceptual model by default or there are possibilities to
the rules in a way that they become sound.
However, an important concept that is not considered by the XMI specification is abstraction,
although abstract classes exist in the MOF specification. This may be a result of
the aim of
the XMI specification, since it should facilitate the interchange of models. This
schemas shall facilitate the validation of models in the form of XMI documents, a
where abstraction plays an inferior role. Considering XML applications that need general
schema concepts, abstraction would be desirable.
Another negative aspect in this context is the declaration of elements for classes,
of instance placeholders as we call them. XMI creates an instance placeholder for each
class without exception. This is always possible, but not always desirable in the
XML applications, because it allows for a variety of valid XML documents implementing
Furthermore, the third drawback is the realization of associations in XMI, which allows
redundancy in instance documents. XMI however targets the validation of models regarding
definition of the according metamodel represented by an XMI schema. Hence, XMI does
emphasize well-structured and easy to use valid documents. Moreover, there are certain
values that make it possible to prevent element declarations for association ends
for the use of an URI-based linking construct that eliminates redundancy. Unfortunately
XMI specification doesn't make use of XLink [W3CRecXLink] at this point, which
could be a helpful concept. This is because the XMI specification was created before
became a W3C standard.
Since the schema generation process can mainly be influenced using tagged values,
we have to
ask for a general set of tagged values to tailor the schema generation process for
Having to annotate each and every model element with cryptic tags doesn't really simplify
software engineer's life. But leaving XMI aside, each transformation process has to
configurable on UML construct level to transfer design decisions into the schema.
Carlson [CarlsonXMLAppsUML] proposes the use of a special UML profile for
XML Schema modeling purposes that defines according stereotypes and tagged values.
he introduces the stereotype “XSDcomplexType” which applied to a class specifies that
class should be realized as a complex XML Schema type. But he also defines stereotypes
tagged values for other model elements like attributes or association ends (e.g. “XSDelement”
or “XSDattribute”) and even stereotypes that target model groups whose function is
other model elements (e.g. “XSDsequence”). This approach surely makes sense, but the
terminology Carlson proposes for the profile belongs to the domain of XML Schema,
not to the
domain of modeling in general. Hence a software engineer has to have domain knowledge
Schema to ensure that the generated schema has the desired properties, and thus in
fact has to
model the schema, not the application. Here we consider it more useful and more general
hide such tags and preset their values sensibly from the perspective of XML applications
modeling in general. This way important patterns, principles and procedures could
and the profile could be made more UML or model specific than XML Schema specific.
The major benefits of using XMI schemas are obviously the possibility of reusing an
specification and the fact that most CASE tools currently support exporting their
XMI documents. The latter fact is important when considering a way to make practical
the XMI rules to create XML Schema documents from UML models in software engineering
Realizing the layer shift using XSLT
XMI compatible UML CASE tools provide the possibility to export models in an XML based,
standardized format, namely an XMI document. This is a welcome fact for the realization
layer shift, which shall create an XMI schema from a conceptual UML model encoded
in an XMI
document. It allows for the insertion of an additional transform layer after the creation
the model during the development process. This means that we get models in a well
format, which we can assume as input format for a transformation. It comes in handy
documents are in fact XML documents, so we can use an XSLT stylesheet to transform
a UML model
encoded in an XMI document into XML Schema.
Naturally the question arises, whether we cannot simply influence the schema generation
process of a UML tool to directly transform a UML model into an XMI schema. This question
inappropriate, though, because UML modeling tools with XMI functionality exclusively
XMI documents, not XMI schemas. The generation of XMI schemas is thus not part of
functionality of the mentioned tools, and hence has it to be done separately after
of a model.
We realize the layer shift with an XSLT 2.0 stylesheet that targets XMI version 2.1
above. Hereby we focus mainly on the XMI specification, which describes the transformation
MOF models into XMI schema documents, but we interpret UML models in particular. As
found out, tagged values (amongst others) are realized in different ways by different
manufacturers. But since they are most important for the tailoring of the schema generation
process, the XSLT stylesheet has to be able to interpret them. As a matter of fact,
interpretation is out of scope for our project and is basically difficult to achieve
of the high degree of flexibility within XMI. However, we support a number of some
of the most
popular tools and integrate an extension point in the stylesheet that makes it easy
additional interpretation modules for further tools. With our implementation we provide
conceptually sound open source realization of the layer shift that can be used in
To make it easy for reuse, we have designed our stylesheet to align with the translation
rules defined by the OMG [OMGXMIMapping] by creating several templates that
correspond to the several subrules and that have the same names as the according rules
official mapping document. Besides interpreting some partially unclear points of the
specification like the handling of package level attributes, we focus on realizing
as consistent with the specification as possible. Furthermore we implement features
for more flexibility than the specification or even provide additional functionality.
are the possibility to use substitution groups for derived model elements, the ability
generate model based name prefixes or the use of XLink for the realization of associations.
enable the use of certain configurations of tagged values, we also provided parameters
allow to set a default value for each tag.
Realizing the layer shift according to the XMI specification naturally leaves its
mark in the
resulting schemas: There are many additional elements and attributes that solely support
interchange process or provide extension points. These XMI-specific schema content
removed for schemas that are generated in the case of document engineering.
Conclusions and related work
In this paper, we have presented a method uml2xsd that transforms conceptual data
their UML representations into XML Schema documents. From a software engineering point
view, our method provides an implementational counterpart to data models that constrains
XML implementations of model instances (data). Our method provides a missing piece
puzzle of data modeling, extending good practice from object-oriented programming
and databases to document engineering.
Clearly, our method provides a missing link in schema engineering: Data modeling can
integrated into system modeling, independently of data implementation technology.
The implementation of xml2xsd builds on XMI, a standard for model interchange that
supported by UML modeling tools. It follows mapping rules from data models to XMI
the OMG has conceptually defined, providing the first publicly available implementation
these rules. Our implementation is open source, configurable and extensible. Hence,
puts forward engineering into the toolbox of schema engineers.
Speaking of schema engineers, even if some project confines itself to pure schema
development, without any ties to software development, our method provides two strong
benefits: First, we enable modeling to be carried out independently of schema technologies.
Second, in the vein of forward engineering, schemas can be generated automatically
We consider the presentation [KimberEtAlUML2DTD] of Kimber and
Heintz at Extreme Markup Languages 2000 as a direct predecessor of our work. We fully
subscribe to their position on the relationships between software engineering, document
engineering and XML technology. In our work, we have taken two further steps: First,
we base our mapping from model to schema on an OMG standard, also facilitating configuration
and extension of the XMI mapping. Second, we offer an implementation that works within
(reasonable) UML environment, requiring, with XSLT, only widely available XML technology.
The work that we have presented here is part of a larger endeavor in which we, the
Engineering Publishing Technology Group, explore to what extent novel publishing applications
can be composed from appropriately configured XML software with a minimum of programming.
goal is to discover principles, patterns and procedures that reduce complexity and
sustainability when developing and maintaining Web applications. Modeling of persistent
and forward engineering of data models into XML schemas are one building block of
for publishing applications that Thomas Schöpf, another member of our group, develops
PhD thesis “Eine Software-Architektur für webbasierte
[AbiteboulEtAlDataOnTheWeb] S. Abiteboul, D. Suciu: Data on the Web: From Relations to Semistructured Data and
XML. Morgan Kaufmann 1999.
[BrüggeEtAlsOOSWE] B. Brügge and A.H. Dutoit. Object-Oriented Software Engineering: Using UML, Patterns
and Java. Second Edition, Prentice Hall, 2004.
[EPTatEML2007] A. Brüggemann-Klein, Th. Schöpf, K. Toni: Principles, Patterns and Procedures of XML
Schema Design — Reporting from the XBlog Project. Extreme Markup Languages 2007.
Available from http://conferences.idealliance.org/extreme/.
[EPTatBalisage2008] A. Brüggemann-Klein, L. Singer: Hypertext Links and Relationships in XML Databases.
Presented at Balisage: The Markup Conference 2008, Montréal, Canada, 2008,
http://www.balisage.net/. Available from
[CarlsonXMLAppsUML] D. Carlson: Modeling XML Applications with UML: Practical E-Business Applications.
Redwood City, Addison Wesley Longman Publishing, 2001.
[ConradEtAlXMLConceptualModeling] R. Conrad, D. Scheffner, J.-C. Freytag. XML Conceptual Modeling Using UML. In A.H.F.
Laender, S.W. Liddle, V.C. Storey (eds), International Conference on Conceptual Modeling
(ER 2000). LNCS 1920, pp. 558—571. Springer-Verlag 2000.
[EcksteinEtAlXMLDatenmodellierung] R. Eckstein, S. Eckstein. XML und Datenmodellierung. DPunkt-Verlag 2004.
[KhanEtAlSchemaDesignPatterns] A. Khan, M. Sum. Introducing Design Patterns in XML Schemata. Sun Developer Network
[KimberEtAlUML2DTD] W.E. Kimber, J.D. Heintz: Using UML To Define XML Document Types. Presentation at
Extreme Markup Languages 2000. Available from
[LainevoolXMLPatterns] T. Lainevool. Develop Effective XML Documents Using Structural Design Patterns.
[MalerEtAlDTDModeling] E. Maler, J. El Andaloussi. Developing SGML DTDs: From Text to Model to Markup.
Prentice Hall 1995.
[OMGMOF] Object Management Group: Meta Object Facility (MOF) Specification. Version 1.4.1,
July 2005. http://www.omg.org/docs/formal/05-05-05.pdf
[OMGMOFCore] Object Management Group: Meta Object Facility (MOF) Core Specification. Version 2.0,
January 2006. http://www.omg.org/docs/formal/06-01-01.pdf
[OMGXMIMapping] Object Management Group: MOF 2.0/XMI Mapping. Version 2.1.1. December 2007.
[OMGUMLInfrastructure] Object Management Group: OMG Unified Modeling Language (OMG UML). Infrastructure,
V2.1.2. November 2007. http://www.omg.org/docs/ formal/07-11-04.pdf
[PaganoDA] D. Pagano. Modeling and Defining XML Applications with UML and XML Schema. Diploma
Thesis, Technische Universität München, 2008.
[StephensonBestPractices] D. Stephenson. XML Schema Best Practices. HP Dev Resource 2004.
[vdVlistSchemaTechnologies] E. van der Vlist. Comparing XML Schema Languages. XML.com 2001.
[vdVlistXMLSchema] E. van der Vlist. XML Schema. O'Reilly 2002.
[W3CRecXLink] World Wide Web Consortium: XML Linking Language (XLink). W3C Recommendation
27 June 2001. http://www.w3.org/TR/xlink/
[W3CRecXMLSchemaStructures] World Wide Web Consortium: XML Schema Part 1: Structures Second Edition.
W3C Recommendation 28 October 2004.