place between two models using the
same metamodel (such as mapping
one XML document to a semantically
equivalent XML document using a
different vocabulary), or it can take
place between models based on different metamodels (such as mapping
an XML document to RDF data). Mapping always takes place between a system model and an exchange model;
this decouples all participating system models.
One of the biggest problems in the
current stack of XML technologies is
there (quite surprisingly) is no appropriate conceptual modeling language
for XML. In terms of the stack of conceptual, logical, and physical models,
XML Schema is not really a conceptual
modeling language; it is primarily focused on markup design. It has some
rudimentary conceptual modeling
features, but is essentially a language
for describing logical models. It is
possible to use existing conceptual
modeling languages (such as ER or
UML) and automatically generate XML
logical models (such as XML Schemas)
from these, but these generated schemas often are not well-designed from
a markup perspective. And critically,
these generated schemas will not support any of the XML features that are
not covered at all by the conceptual
modeling language used as the starting point (most notably, support for
narrative structures with mixed content).
This means the ideal process shown
in the figure currently lacks support
for the conceptual model layer of the
exchange model (assuming XML as
the exchange model’s physical model). In many cases, applications use
their own adhoc conceptual models
and the logical model (such as an XML
Schema) is then augmented with additional information to also serve as the
conceptual model, or to refer to it.
Popular web metamodels
XML metamodels (as described earlier) are the most popular metamodels for Web data and services, but they
sometimes are thought of as being too
expensive in terms of processing, especially if the data model being represented is simple. An alternative physical model for XML metamodels is
the JavaScript Object Notation (JSON),
we strongly
recommend
the design
of documents
be informed
by potential
consumers
and their use
cases, not by
the producers
of documents.
which can only encode a subset of possible XML structures, and represents
this subset in a way that can be interpreted as a JavaScript object. JSON is
useful if the peers (or at least one of
them) are JavaScript-based, and if the
restrictions of the JSON syntax (no
mixed content, restricted names, no
difference between elements and attributes, no ordering) are acceptable
for the exchange model.
A popular metamodel alternative to
XML is RDF, the model of the Semantic Web. It is a metamodel based on
triples, which can be used to construct
complex graph structures. RDF works
well for representing graphs, but has
no specific support for the narrative
end of the document type spectrum,
which is well supported by XML. And
while RDF is the universally accepted
metamodel in the Semantic Web community, its use as an exchange model
still limits the potential set of peers
considerably more than an XML metamodel, because RDF tools are not as
ubiquitous as XML tools.
topology troubles
The idealized matching of models
shown in the figure can become complicated when the structures supported by the metamodels do not match
very well. A typical example is when
the data model is defined in UML and
is able to represent arbitrary graphs.
XML is tree-structured and thus not
a good fit for such a model. In such a
case, there are two basic alternatives:
˲ If the model is defined using some
tool, in many cases these tools provide
“export” or “generate schema” facilities for exporting the model as an
XML Schema. While technically these
generated schemas are XML representations of the model, typically they are
rather cumbersome to work with on
the XML level, because they are generated from a generic mapping of the
metamodel to XML, and consequently
do not take into account any specifics
of the actual model.e
˲ The other possibility is to use the
approach we described earlier and as-
e More advanced tools support annotating the
model so that the mapping can be guided by
annotations. This method yields better results
as generated schemas, but the fundamental
problem of misaligned metamodels of course
cannot be changed.