"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Domain Modelling using Hollow World


Related pages

What is HollowWorld?

First read HollowWorld.

What is a domain model?

A domain model or Application Schema should describe all the feature-types involved in transactions and operations in the domain. Since different aspects of a feature may be required for operations in different domains of discourse, the characterization of a feature-type may not be universal or comprehensive. It is merely necessary for the definition of a feature-type to accommodate the properties relevant to operations within the domain.

Thus, scoping the domain is an important pre-requisite to make the domain-modeling exercise tractable, and the domain model only concerns the views of the feature-types required for operations within that domain.

Further details of domain analysis are beyond the scope of this document, the remainder of which concerns the formalization of a domain model, and its conversion to a GML-conformant XML Schema.

Packaging and dependencies

The feature types in a domain model will be owned by one or more UML packages with the stereotype «ApplicationSchema». An application schema which has been developed to be conformant with the ISO/OGC framework
  • may contain sub-packages but these shall not be stereotyped «ApplicationSchema»
  • will have dependencies on packages from the ISO Harmonized Model (e.g. ISO 19107 for geometry, ISO 19123 for coverages)
  • may have dependencies on packages from other domains (e.g. GeoSciML depends on Observations and Measurements
  • may have dependencies on more primitive packages from the domain of interest (e.g. Geologic Timescale depends on GeoSciML

Some of these dependencies need to be explicitly modelled for the model compilation process. In general the ISO package dependencies are handled during model compilation, however the others should be explicitly exposed in a diagram that makes such dependencies clear to users of the model. (see UMLAutomationImprovements )

Formalize the model


  • See ConfiguringUMLToolForHollowWorld
  • Make sure the Tagged Values pane is visible
    • Main menus: View→Other windows→Tagged values
  • Take a tour of the template model, paying particular attention to the base-classes provided in the ISO_TC_211, OM and Utilities packages

Create a structure diagram

  1. select Project Browser: Model→Domain Models→MyDomainModel→MyPackage1
  2. right-click Add→Add Diagram to create a new class diagram in this package

Add classes and properties

In the Class Diagram
  • modify the template, add properties, rename classes, delete unwanted items
  • add components to your model, following the rules from SchemaFormalization
  • all classes must carry the appropriate «Stereotype»
    • this indicates which pattern to use in the XML Schema implementation
    • a convenient way to add new Packages and Classes, with a standard SchemaFormalization «stereotype», is to drag-and-drop
      • in the Resources Pane, find the Resources→UML Profiles→UML Profile for GML Application Schemas
      • find the appropriate class stereotype, and drag-and-drop it into the diagram
      • in this mode, the standard Tagged values for each stereotype are created automatically
    • alternatively, generic elements components can be added from the Toolbox;
      • stereotypes can be added using the Properties dialogue for the relevant element
        • remember: no stereotype«Type»
      • in this mode, the standard Tagged values for each stereotype should be added by "synchronising" the model with the UML Profile
        • in the Resource Pane → Resources→UML Profiles→UML Profile for GML Application Schemas, right click on each stereotype element and select Synch Tagged Values and Constraints
        • ALERT! WARNING: if you run this operation multiple times on the same model, you will get multiple tagged values with the same name, leading to unpredictable behaviour from a processor (e.g. FullMoon) ALERT!
  • for each component represented as a class
    • add a Generalize link to the required parent class
      • e.g. for specialized SamplingFeatures or Specimen types, the parent should be a suitable class from the O&M2 package;
      • if you know which package the required class is in, navigate to it in Project View then drag-and-drop onto the diagram containing the class that you want to link to
      • if you don't know which package the other class is in, use the Main menu: Edit→Find Object dialogue, select the object of type Class, and then click Locate Selected
    • add class attributes corresponding to properties with simple values, and properties whose values are tightly bound to the class instance
    • add associations corresponding to properties whose values are other classes

Hint: Specific patterns applicable to modelling schemas for Observation applications is given at OandMCookbook. This includes a discussion of the components available for use in models intended for automatic schema generation.

Organize the model

  • rename MyDomainModel to something appropriate for your subject
    • select the component and use the Properties pane, or double-click the component and use the dialogue
  • rename MyPackage1 to something appropriate to the schema
  • add new packages and diagrams as appropriate
  • sort the classes and type definitions into the packages by drag-and-drop in the Project View pane

Prepare for XML implementation

Set required Tagged Values

Along with "Stereotypes", "Tagged Values" are the primary extensibility and customization mechanism provided in UML. While Stereotypes are used to extend the UML meta-model to support additional concepts at the model level, Tagged values are used to provide various directives required for specific implementation platforms.

  • For every class property (i.e. attribute or association-end)
    • set the value of inlineOrByReference to "inline" or "byReference" to limit the implementation if required
    • set the value of isMetadata to "true" if it is intended that this property be treated as indexable metadata
    • set the value of sequenceNumber to a unique integer, to direct the ordering of XML elements representing properties in the implementation
  • For every Package, set the stereotypes and Tagged Values
    • every package that is intended to represent a complete schema in a distinct namespace must be stereotyped «Application Schema»
      • it is essential that the following Tagged Values are set:
        • targetNamespace (usually a URL)
        • xmlns (the namespace prefix that will be used in the schema documents)
        • xsdDocument (the filename that will be used for the actual schema document)
    • any subsidiary package that is intended to be implemented as a discrete XML Schema document must be stereotyped «Leaf»
      • it is essential that the following Tagged Value is set:
        • xsdDocument (the filename that will be used for the actual schema document)
      • Note: Leaf packages the same targetNamespace and xmlns as their parent Application Schema

NOTE: in order to generate the GML Application Schemas, it is essential that the Tagged Values are set correctly on the Packages. On other components the Tagged Values are more for fine-tuning.

NOTE: There should be no duplicate tagged values - i.e. there must only be one tagged value of the same name on each element.

To verify in Enterprise Architect, open Tools->Options->Objects and check "show duplicate tagged values" to be "true".

Record package dependencies

Internal dependencies

If your model is factored between several packages, these will be implemented as separate W3C XML Schema Documents, and the required import/include relationships must be provided. While dependencies between packages are (strictly speaking) implied by the dependencies between members, in order for the automatic code generation to proceed, the package dependencies must be explicitly described.

  1. create new diagrams to capture the relationships between the packages
    • in the New Diagram dialogue, select Structural Diagram - Class and give it the name "Package dependencies"
  2. populate the diagram by drag-and-dropping required packages from the Project View window
  3. add Dependency or Pkg Import associations between packages, to reflect the logical dependencies, so that the arrow-head on each association points to the more primitive package.
    • a dependency must be shown from each Leaf package to every package that provides classes used directly by it; classes are used either
      1. as a parent class,
      2. as the target of an association, or
      3. as the type of a class attribute
    • dependencies are transitive within a single Application Schema
    • dependencies to external Application Schemas shall be given only to the external package stereotyped «Application Schema» which acts as the interface package to the whole external Application Schema
    • dependencies to external packages with other stereotypes are allowed, but will only be implemented in XML if there is a published XML implementation of the package - see ExternalDependencyConfiguration
    • if external references to your local Application Schema are allowed, the local package stereotyped «Application Schema» should appear in the local Package dependencies diagram, with dependencies shown to such local Leaf packages which will allow it to include (directly and indirectly) all the components in the local Application Schema.

NOTE: these packaging dependency rules shadow the include/import behaviour within W3C XML Schema composition: dependencies within a single application schema are implemented as include; dependencies between application schemas are implemented as import.

External Dependencies

See ExternalDependencyConfiguration

Common "Gotchas"

  1. When adding class attributes, set their type from the drop-down menu in the dialogue box. If you don't do this (for example, if you enter the type name as a text string), the attribute type will not be properly associated with the corresponding class definition.

Export the model as an XMI document

The model must be exported in the standard software-independent XMI format, for further processing to generate the GML Application Schema.

The model will be processed one application-schema at a time. Managing dependencies on external packages is part of the configuration phase for the processing tool.

In the Project View window
  • right-click on a package stereotyped «Application Schema»
  • Import/Export → Export Package to XMI file ...
  • General Options
    • check Format XMI Output
    • check Use DTD
    • check Generate Diagram Images - Format: GIF
  • For Export to Other Tools
    • check Enable full EA Roundtrip,
    • select XMI type "UML 1.3 (XMI 1.1)"
  • set convenient destination Filename
  • Export

Packaging and model dependencies


Following ISO 19109, the quantum of analysis and design is the "Application Schema". Consistent with this, FullMoon processes models one «ApplicationSchema» at a time.

If your model has dependencies on packages other than GML, then FullMoon requires configuration information for the XML implementation of the external packages. This applies even if you own the additional packages.

Dependency artefacts

All dependencies that the model has on components from other packages must be resolved in order for FullMoon to be able to perform a transformation, such as generating an encoding. Dependencies are managed through
  1. an explicit register of implementations of external packages
    • a default register is provided as part of the FullMoon distribution, which covers many of the packages from HollowWorld
  2. a set of class maps, at least one for each external package

For more details, see ExternalDependencyConfiguration

Generate the GML Application Schema

Go to FullMoon

Topic revision: r17 - 08 Feb 2012, SimonCox

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).