Balisage Paper: Prying Apart Semantics and Implementation

Introduction

Schemata in the World Wide Web Consortium's (W3C) Extensible Markup Language (XML) Schema language (XSD), Relax Next Generation (RNG), Structured Query Language (SQL) Data Definition Language (DDL), Resource Description Framework Schema (RDFS), or Web Ontology Language (OWL)) are typically created directly. A basic text editor can be used, although more likely today it will be with a design tool that uses visual symbols with a more or less bijective mapping to the constructs in the chosen implementation language. Various profiles of the Unified Modeling Language (UML) class diagrams have been proposed as a visualization for XSD design Bernauer-2004; various forms of Entity Relationship Diagrams (ERD)'s are the preferred choice for relational database (SQL DDL) design. And then there are the numerous languages specific to a given vendors tool.

As useful as these visual design languages are, they are first, representations of a design in a specific implementation language, and only secondarily do they reflect the semantics of a Universe of Discourse (UoD) or domain.^[1] Or as stated in the introduction to Guizzardi-2005 pages 7 - 8.

Designs reflect hard engineering trade-offs, starting with the initial choice of an implementation language which will have only limited abilities to express the full richness of the UoD, and ending with the numerous design choices made (e.g., denormalization, implementing relationships, by reference, vs. by value, collapsing generalization hierarchies). This intertwining of implementation design and semantics with semantics taking a back seat, means that no formal model representing just the semantics remains. The sole guardian of pure semantics is the informal prose, in the text box labeled Description.

The use of prose to capture semantics is of course essential, the target audience that needs to fully account for semantics are people, and natural language with all its richness, complexity, and nuance is essential. The challenge of course with relying only on words is their ambiguity. Although formally the interplay of words with meaning is studied in fields such as linguistics, semiotics, phenomenology, communication theory etc., Humpty Dumpty sums up the problem rather well.

The lack of a separate design neutral, but formal accounting of semantics has several drawbacks. The first, is that ultimately for two or more systems to interoperate they must share a compatible understanding of the UoD, they needn't necessarily share the same design. This task of determining, and ultimately documenting via a mapping, compatibility, or recognizing when and where it is not possible is made more difficult. Second, when people negotiate to decide on a common language for sharing information, the discussion can / will often stray between discussing differences in meaning, and differences in design. Its helpful in resolving disagreements to know which of the two classes of discussion one is having. Third, it is perfectly reasonable, desirable, and necessary to implement the same UoD in multiple implementation languages and/or in multiple designs. Capturing explicitly a model of the UoD allows it to be reused. This is even more beneficial if the domain is highly complex and/or technical and modeling it correctly is expensive, time consuming and difficult.

A solution, is to create a conceptual model (CM). A model that formally represent those aspects of the UoD that are deemed relevant for a particular purpose, (e.g., the static structural aspects of a domain essential to the development of information models), but that is neutral of physical design decisions. Then from that model produce though a semi-automated mapping process logical / physical level models, from which, because of their isomorphism to a targeted schema language, a schema can be automatically produced.

The idea is hardly new.The issue is essentially one of implementation independence - the goal (or assumption) that the conceptual data model be independent of the implementation language. This view dates at least from Chen (1976), is the basis of the conceptualization principle in the ANSI/SPARC framework ISO-TR9007, and has been frequently re-stated ... This ideal does not appear to be achieved in practice (Simsion-2007, p. 51). Nor is the idea unique to the data modeling community from which the above quote originates. The Model Driven Architecture (MDA) of the Object Management Group (OMG) has the concepts of the Platform Independent Model (PIM) and Platform Specific Model (PSM) OMG-MDA. The recognition of the need for conceptual models to back up XML schema design is also old, dating back to the beginning of XML, and XML's predecessor, Standardized Generalized Markup language (SGML).^[2]

The proposal outlined in the sections that follow is also in one sense nothing new. Its strength is not in the idea that a conceptual model is useful, but in what modeling language has been pressed into service. The conceptual modeling language outlined below, is a subset of that proposed by Giancarlo Guizzardi, principally in Guizzardi-2005 . In his 2005 work, a foundational ontology in later works referred to as the Unified Foundational Ontology (UFO), designed to capture agreements about the semantics of a UoD by people and for people, visualized using a profile of UML 2.0 is defined. We have changed, only trivially his proposal based on some ideas from data modeling Simsion-2005 and other sources both to simplify the language, and make it more familiar to people with a data modeling background. The UFO builds upon cross disciplinary knowledge as well as research in formal ontology [as applied to computer science] that has occurred in the last fifteen years.

From a conceptual model based on this language, multiple physical data models (PDM) which subset, and / or extend, the larger conceptual model are generated. A PDM is then annotated by a designer with a set of encoding options that specify how the concepts in the CM should be represented in the XSD. We have chosen the initial set of encoding options based on internal experience with creating UML to XML schema mappings since 2000-2001 much like those surveyed in Bernauer-2004. Software written in Extensible Stylesheet Transformations (XSLT) version 2.0 is the primary mechanism by which the annotated physical data models are compiled into XML schemata. Figure 1 show an overview of the complete process.

Figure 1: Model Development Process

In the following sections, our requirements for a CM modeling language are explained, followed by a brief outline of the ontologically well founded language we have selected. This is followed by an example physical data model, that has been annotated with XSD encoding directives. How those directives drive the compilation of that PDM into an XSD is explained. The software implementation in Sybase Power Designer (a commercial data modeling / enterprise architecture tool), and in particular the implementation of the XSLT code that generates an XML schema from it, is touched on briefly. This is followed by a section on further work, and conclusions. Appendix A contains a more complete account of the XSD encoding options available.

Semantics

An Ontologically based Conceptual Modeling Language

This frequently repeated quote represents a very pragmatic definition of what makes a good model and it is the position adopted here for both models, and by extension modeling languages and the meta-models / ontologies that they are based on. As such, no claims are made that the modeling language briefly introduced below, the foundational ontology it is based on, or the models that are described with it, have any lock on a single, absolute truth. Instead, the language has been chosen / customized because we believe it can meet the following pragmatic requirements^[3]:

After attempting to adapt unsuccessfully both standard UML and ERD notations to meet the above requirements, the realization through both experience and subsequent examination of the literature (e.g., Simsion-2007 ), was that both languages, and the informal ontologies that they are based on, were too biased for design in a specific technology. This led us to examine how formal ontology^[10] could be employed, not in the computer science sense of producing a specific artifact, expressed typically in a formal logic variant, but in the philosophical sense.

In the end we settled on the formal foundational ontology, and its representation in UML defined in Guizzardi's 2005 PhD thesis Guizzardi-2005 and subsequent research papers Guizzardi-2006a Guizzardi-2006b Guizzardi-2007 Guizzardi-2008 to name just a few, that define the Unified Foundational Ontology (UFO). Some small changes in terminology were made to make the UFO more approachable to classically trained ERD modelers. Its also important to point out that no claim is being made that the UFO is the only upper level ontology that will meet the requirements outlined above. What is being claimed is that the selection and explicit recognition of a formal upper level ontology as the basis for domain ontologies / models is essential to give those models the precise semantic underpinning needed to enable interoperability. What follows is a necessarily brief introduction to UFO and its representation in UML.

This ontology / language is used to facilitate communication between people, although admittedly it is not something that a person, without training will fully grasp. [The ontology ] aims at capturing the ontological distinctions underlying human cognition and common sense.Guizzardi-2005 The ontology is the basis for recording one, (among many possible) conceptualizations of the real-world, defining what is a valid state of that world. As such, the language symbols designate real-world objects, and not information structures as is the case is the PDMs derived from it. Optionality on attributes and relationships is strongly discouraged^[11], ... from an ontological standpoint, there is no such a thing as an optional property and, hence, the representation of optional cardinality leads to unsound models (in the technical sense of chapter 2), with undesirable consequences in terms of clarity (Guizzardi-2005, p. 139).

Design

XML Schema Encoding Annotations

The design phase that ends with the ability to automatically generate an XSD starts by creating a copy of some subset of the larger conceptual model. During this generation phase the target implementation language is selected, in this case the target language is a W3C XML schema. This subset copy, called a physical data model (PDM) is then modified in two ways. First, additional diagrams may be added to tell a story customized to specific perspective that a customer has over a UoD. Second, the physical model is changed. Anything can be changed including the addition or deletion of modeling constructs as needed. The more common changes include renaming concepts to reflect preferences by a customer.^[14], selecting which attributes will function as keys, changing the navigability on associations, and the selection of specific XSD encoding options.

Both properties defined by UML 2.0 (e.g., association end navigability) and additional properties added as extensions to base UML are used. Some model properties apply globally to the entire model, and thus affect the entire XSD being generated (e.g., the namespace of the XSD), others apply to the encoding of a specific modeling construct (e.g., class, attribute). In some cases the same property can appear both globally and locally. If so, precedence is given to the local value. Most encoding options have default values (e.g., [UML] attributes get encoded as xsd:element). If an encoding style is being used see Appendix A, whole sets of encoding options plus built in logic that keys off of the semantic constructs in the model get enabled. Thus a default XSD can be produced with minimal effort. Yet fine grained control can also be exercised by setting individual encoding properties if desired.

A complete enumeration and explanation of all of the available encoding options is beyond the current scope. A brief summary of the most common options is contained in Appendix A. Below, a subset of the example model introduced above is used to explain how one set of encoding options produces an XSD.

Software

The creation and maintenance of multiple layers of models and the subsequent generation of XSDs would not be feasible without the correct tooling. The modeling tool we use is Sybase Power Designer; a market leading tool in traditional [relational] data modeling. It was selected for a variety of reasons, not the least of which is its extensive ability to be customized, and ability to generate / merge / compare / track the relations between multiple models. It has been customized to support and enforce the rules of the conceptual modeling language outlined above. This has involved extending the meta-model that underlies Power Designer with additional [extended] properties, modifying the forms displayed under certain menus, and writing additional trigger code to enforce the rules of the conceptual modeling language (e.g., section “Conclusion”). The code that create the XSD has been implemented outside of Power Designer to avoid coupling it to a particular vendor's product.

The architecture for this XSD complier, called unimaginatively Model2XSD is shown below Figure 6. A relatively simple routine written inside Power Designer in visual basic script serializes the model as XML based on a custom designed markup language.^[15] An XSLT 2.0 pipeline is then called to compile the XML into an XSD. The XSLT program consists of several processing stages and supporting libraries of functions and configuration files. The Model2XSD-Preprocessor is used to add additional constructs to the serialized model file if needed based on selected encoding options. The Model2XSD-Processor creates the XSD. Finally the Model2XSD-Postprocessor, optionally, does certain XSD clean-up activities that can simplify the resultant schema.^[16] All of these pieces of code are backed up by two function libraries, Model-Utility primarily contains functions that navigate the physical model as represented in XML (e.g., getting a concept's supertype, all its subtypes, etc.). This library does not contain any functions specific to the generation of an XSD and thus could be reused in other generation tasks.Model2XSD-Utility" contains functions specific to the generation of XSD files.

Figure 6: Model2XSD Process Flow

Further Work

Our application of the techniques outlined above is in its infancy. As we continue to gain experience, refinements in both the conceptual modeling language, the encoding rules for XSD, and the software support for all of the above are inevitable. It is possible that we will see the benefit of adopting more of the UFO, or possibly less. As we develop more XSDs we will undoubtedly have requirements for incrementally adding to our tool box of encoding annotations. It is a testament to the strength of the conceptual modeling language that thus far we have been able to algorithmically generate any necessary encoding we need.

In roughly priority order these are the current areas of interest we are pursuing:

Conclusion

The adoption of a multi-layered model development process consisting of one (or a small number of) conceptual models as the basis for potentially many physical implementation models; the selection / customization of the UFO visually represented as UML class diagrams, as a conceptual modeling language; the design of rules for compiling these models into an XSD; and the implementation of all of the above using Sybase Power Designer and XSLT is all still relatively new. We have only recently started exercising this methodology fully to deliver products (XSDs) to internal customers. We are still learning, and further customizing our techniques and their implementation in software. So far our experience with using these techniques is anecdotal. It is both sobering and promising...

<xsd:complexType name="Manufacturer"> ...

<Manufacturer/>

<xsd:group name="ManufactureredItem> ...
and / or
<xsd:attributeGroup name="ManufacturedItem"> ...

N/A

<xsd:simpleType name="uuid">
    <xsd:restriction base="xsd:string">
        <xsd:pattern value="[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}"/>
    </xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="colorEnum">
    <xsd:restriction base="xsd:string">
        <xsd:enumeration value="red"/>
        <xsd:enumeration value="yellow"/>
        <xsd:enumeration value="blue"/>
        <xsd:enumeration value="green"/>
    </xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="rgbColorStruct">
    <xsd:list itemType="xsd:integer"/>
</xsd:simpleType>

<xsd:simpleType name="colorUnion">
    <xsd:union memberTypes="rgbColorStruct colorEnum"/>
</xsd:simpleType>

<xsd:complexType name="CPU">
    <xsd:attribute name="signature" type="xsd:string"/>
</xsd:complexType>

<CPU signature="Intel(R) Pentium(R) M"/>

<xsd:complexType name="CPU">
    <xsd:sequence>
        <xsd:element name="Signature" type="xsd:string"/>
    </xsd:sequence>
</xsd:complexType>

<CPU>
    <Signature>Intel(R) Pentium(R) M</Signature>
</CPU>

<xsd:complexType name="CPU">
    <xsd:simpleContent>
        <xsd:extension base="xsd:string"/>
    </xsd:simpleContent>
</xsd:complexType>

<CPU>Intel(R) Pentium(R) M</CPU>

<xsd:group name="ManufacturedItem">
    <xsd:sequence>
        <xsd:element name="SerialNum" type="xsd:string"/>
    </xsd:sequence>
</xsd:group>

<xsd:attributeGroup name="ManufacturedItem">
     <xsd:attribute name="computerMaker" use="required" type="Manufacturer"/>
</xsd:attributeGroup>

<xsd:complexType name="Hardware">
    <xsd:sequence>
        <xsd:group ref="ManufacturedItem"/>
    </xsd:sequence>
    <xsd:attributeGroup ref="ManufacturedItem"/>
</xsd:complexType>

<Hardware computerMaker="Dell">
    <SerialNum>1234</SerialNum>
</Hardware>

<xsd:group name="ManufacturedItem">
    <xsd:sequence>
        <xsd:element name="ComputerMaker" type="xsd:string"/>
        <xsd:element name="SerialNum" type="xsd:string"/>
    </xsd:sequence>
</xsd:group>

<xsd:complexType name="Hardware">
    <xsd:sequence>
        <xsd:group ref="ManufacturedItem"/>
    </xsd:sequence>
</xsd:complexType>

<Hardware>
    <ComputerMaker>Dell</ComputerMaker>
    <SerialNum>1234</SerialNum>
</Hardware>

<xsd:group name="ManufacturedItem">
    <xsd:sequence>
        <xsd:element name="ComputerMaker">
             <xsd:complexType>
                 <xsd:attribute name="name" use="required" type="xsd:string"/>
             </xsd:complexType>
        </xsd:element>
        <xsd:element name="SerialNum" type="xsd:string"/>
    </xsd:sequence>
</xsd:group>

<xsd:complexType name="Hardware">
    <xsd:sequence>
        <xsd:group ref="ManufacturedItem"/>
    </xsd:sequence>
</xsd:complexType>

<Hardware>
    <ComputerMaker name="Dell"/>
    <SerialNum>1234</SerialNum>
</Hardware>

<xsd:group name="ManufacturedItem">
    <xsd:sequence>
        <xsd:element name="ComputerMaker">
             <xsd:complexType>
                <xsd:sequence>
                    <xsd:element name="name" type="xsd:string"/>
                </xsd:sequence>
             </xsd:complexType>
        </xsd:element>
        <xsd:element name="SerialNum" type="xsd:string"/>
    </xsd:sequence>
</xsd:group>

<xsd:complexType name="Hardware">
    <xsd:sequence>
        <xsd:group ref="ManufacturedItem"/>
    </xsd:sequence>
</xsd:complexType>

<Hardware>
    <ComputerMaker>
        <Name>Dell</Name>
    </ComputerMaker>
    <SerialNum>1234</SerialNum>
</Hardware>

<xsd:group name="ManufacturedItem">
    <xsd:sequence>
        <xsd:group ref="Manufacturer"/>
        <xsd:element name="SerialNum" type="xsd:string"/>
    </xsd:sequence>
</xsd:group>

<xsd:complexType name="Hardware">
    <xsd:sequence>
        <xsd:group ref="ManufacturedItem"/>
    </xsd:sequence>
</xsd:complexType>

<Hardware>
    <ManufacturerName>Dell</ManufacturerName>
    <ManufacturerSize>large</ManufacturerSize>
    <SerialNum>1234</SerialNum>
</Hardware>

<xsd:group name="ManufacturedItem">
    <xsd:sequence>
        <xsd:element name="ComputerMaker" type="Manufacturer"/>
        <xsd:element name="SerialNum" type="xsd:string"/>
    </xsd:sequence>
</xsd:group>

<xsd:complexType name="Hardware">
    <xsd:sequence>
        <xsd:group ref="ManufacturedItem"/>
    </xsd:sequence>
</xsd:complexType>

<Hardware>
    <ComputerMaker>
        <Name>Dell</Name>
        <Size>Large</Size>
    </ComputerMaker>
    <SerialNum>1234</SerialNum>
</Hardware>

<xsd:group name="ManufacturedItem">
    <xsd:sequence>
        <xsd:element name="ComputerMaker">
            <xsd:complexType>
                <xsd:attributeGroup ref="xlink:XlinkSimple"/>
            </xsd:complexType>
        </xsd:element>
    <xsd:element name="SerialNum" type="xsd:string"/>
    </xsd:sequence>
</xsd:group>

<xsd:complexType name="Hardware">
    <xsd:sequence>
        <xsd:group ref="ManufacturedItem"/>
    </xsd:sequence>
</xsd:complexType>

<Hardware>
    <ComputerMaker xlink:href="Dell"/>
    <SerialNum>1234</SerialNum>
</Hardware>

<xsd:group name="ManufacturedItem">
    <xsd:sequence>
        <xsd:element name="ManufacturedBy">
            <xsd:complexType>
                <xsd:sequence>
                    <xsd:element name="ComputerMaker" type="xsd:string"/>
                </xsd:sequence>
            </xsd:complexType>
        </xsd:element>
        <xsd:element name="SerialNum" type="xsd:string"/>
    </xsd:sequence>
</xsd:group>

<xsd:complexType name="Hardware">
    <xsd:sequence>
        <xsd:group ref="ManufacturedItem"/>
    </xsd:sequence>
</xsd:complexType>

<Hardware>
    <ManufacturedBy>
        <ComputerMaker>Dell</ComputerMaker>
    </ManufacturedBy>
    <SerialNum>1234</SerialNum>
</Hardware>

<xsd:complexType name="ManufacturedBy">
    <xsd:sequence>
        <xsd:element name="ComputerMaker" type="xsd:string"/>
    </xsd:sequence>
</xsd:complexType>

<ManufacturedBy>
    <ComputerMaker>Dell</ComputerMaker>
</ManufacturedBy>

<xsd:complexType name="ColorPrinter">
    <xsd:complexContent>
        <xsd:extension base="Printer">
            <xsd:sequence>
                <xsd:element name="colorLevel" type="xsd:positiveInteger"/>
            </xsd:sequence>
        </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>

<ColorPrinter type="ColorPrinter">
    <Name>ColorPrinter1</Name>
    <ColorLevel>8</ColorLevel>
</ColorPrinter>

<xsd:complexType name="ColorPrinter">
    <xsd:sequence>
        <xsd:group ref="Printer"/>
        <xsd:element name="ColorLevel" type="xsd:positiveInteger"/>
    </xsd:sequence>
    <xsd:attributeGroup ref="Printer"/>
</xsd:complexType>

<ColorPrinter type="ColorPrinter">
    <Name>ColorPrinter1</Name>
    <ColorLevel>8</ColorLevel>
</ColorPrinter>

<xsd:complexType name="Printer">
    <xsd:sequence>
        <xsd:element name="Name" type="xsd:string"/>
        <xsd:choice minOccurs="0">
            <xsd:element name="BWPrinter" type="BWPrinter"/>
            <xsd:element name="ColorPrinter" type="ColorPrinter"/>
        </xsd:choice>
    </xsd:sequence>
    <xsd:attribute name="type" use="required" type="xsd:string"/>
</xsd:complexType>

<Printer type="ColorPrinter">
    <Name>ColorPrinter1</Name>
    <ColorPrinter>
        <ColorLevel>8</ColorLevel>
    </ColorPrinter>
</Printer>

<xsd:complexType name="Printer">
    <xsd:sequence>
        <xsd:element name="Name" type="xsd:string"/>
        <xsd:choice minOccurs="0">
            <xsd:group ref="BWPrinter"/>
            <xsd:group ref="ColorPrinter"/>
        </xsd:choice>
    </xsd:sequence>
    <xsd:attribute name="type" use="required" type="xsd:string"/>
</xsd:complexType>

<Printer type="ColorPrinter">
    <Name>ColorPrinter1</Name>
    <ColorLevel>8</ColorLevel>
</Printer>