Rest modeling layers.

match between system model 1 and exchange model

match between exchange model and system model 2

conceptual model

system Model (er)

exchange Model

system Model (oWl)

Logical model

relational tables

XMl schema

rdF

Physical model

rdbMs

serialization (XMl, eXi)

rdF/XMl, rdF store

 

shared, the participants can be more tightly coupled (often necessary for performance reasons) than when it is not, they can for example access the model through fine-grained functions that provide direct access to the model’s components; in contrast, the loose coupling embodied in resource exchange enables easier substitution of service providers, which is often desirable for business reasons.

We call the internal models that participants have system models, and the representation model used for communication the exchange model. One complication in REST is the fact that both models have metamodels, and for successful collaboration it is necessary that the metamodel of the exchange model is made explicit, and is sufficiently described to match it to system models and thus to collaborate.

the importance of metamodels

Many real-life problems in Web Service architectures are rooted in implicit assumptions about metamodels. Two examples can be used to illustrate the role of the metamodel for the exchange model, and why it is important in the design of a REST architecture.

The first example starts with a tiny difference between “plain XML” and a data model’s metamodel. If a data model is based on DTDs or XML Schema, it may use default values, which are not part of the XML syntax itself, but de-

fined by these schema languages for the metamodel. Applications processing the XML without using the DTD or the XML schema will not recognize these default values, because they are part of a specific schema-based metamodel, and encoded in the schema, not in the instance. Other XML mechanisms—for example XML Namespaces, XML Base, and XInclude—can also affect the interpretation of the model, because a model based on any of these specifications has to be interpreted according to their rules. Thus, even for something as interoperable as XML, it is essential to be explicit about the metamodel that is assumed as governing the data.

The second example is based on another popular metamodel, the Semantic Web. The Semantic Web’s metamodel is RDF, and depending on the application, there often is a Schema defining a model for that metamodel (schemas for the Semantic Web are often called ontologies). RDF has several possible serializations; one of them is RDF/XML, where RDF triples are serialized as an XML document. For a peer in such a scenario to work correctly, it must parse the RDF/XML, and then transform the resulting XML document tree into a set of triples, a task that is non-trivial because of the syntax variations defined by RDF/XML. In addition, if there is a schema for the model, it must be taken into account when working with the RDF data, be-

cause Semantic Web applications should deal with the deductive closure of the RDF graph they process, not the (syntactic) graph itself. So while XML is being used in this scenario, it only appears on the level of the physical model (as the serialization format), whereas the logical model is RDF.^c

These two examples illustrate the importance of metamodels for the exchange model. Depending on the choice of the metamodel for the exchange model, peers are required to understand and implement the metamodel and the schema language that encodes the semantics as well as additional constraints for the data model.

There are a number of XML metamodels (after all, XML itself is only a syntax⁵), all of which are tree-based, but they use slight variations of the basic XML structures: The XML Information Set (Infoset) is the oldest metamodel of XML; its main contribution is that it includes XML Namespaces in the metamodel. The Post Schema Validation Infoset (PSVI) is XML Schema’s variant of an XML metamodel; its main contribution is its support for typed trees. The XQuery 1.0 and XPath 2.0 Data Model (XDM) is becoming the defacto standard for XML metamodels; its main contribution is its support of sequences and thus the ability to represent non-XML values as well as XML trees. In addition to these basic XML metamodels, applications may choose to support additional metamodel features such as XInclude. Extensibility and versioning support often are desirable properties of data models, but for the XML metamodels listed here these are not readily available as metamodel features. Instead, they must be implemented by the data model, and best practices and design patterns can be used for guiding such a design.

aPis use metamodels

When API designers use popular

c Because RDF/XML is just a syntax for RDF data, it is also possible to serialize RDF as non-XML data; a popular format for this is Notation 3 (N3). In such a scenario, it becomes even more apparent that RDF and XML have very little in common, and that RDF’s XML syntax is just an implementation detail of a specific serialization, and does not provide interoperability on a higher level.