XML Schema Conversion

From Developer Documents
Jump to: navigation, search

Simantics XML-Schema Conversion version 0.1


  • org.simantics.xml.sax
  • org.simantics.xml.sax.base
  • org.simantics.xml.sax.ui


Simantics XML-Schema conversion creates:

  • Simantics ontology as .pgraph file
  • Java classes for SAX based parser

Schema conversion does not support:

  • XML file export
  • Many of the XML schema definitions
  • Group definitions
  • Attribute constraining facets


This work was done in PDS Integration project in co-operation with VTT and Fortum. Schema conversion was used for converting Proteus 3.6.0 XML Schema to Simantics ontology. Due to limited scope of the schema, the converter supports only limited part of the XML Schema definitions.

Ontology definitions based on XML schema concepts

XML Schema conversion creates types and relations based on XML schema concepts that are used in the conversion

Hard-coded ontology definition Notes
hasAttribute <R L0.HasPropertyBase relation for all element/attribute relations
hasID <R hasAttribute Base relation for IDs (Attributes with xsd:ID type)
ComplexType <T L0.Entity Base type for ComplexTypes
hasComplexType <R L0.IsComposedOf Base relation for containing elements that inherit the specified ComplexType
AttributeGroup <T L0.Entity Base type for AttributeGroups
Element <T L0.Entity Base type for Elements
hasElement <R L0.IsComposedOf Base relation for containing elements
ElementList <T L0.List Base type for Lists containing Elements (storing the order of the elements)
hasElementList <R L0.IsComposedOf Base relation for element containing element lists. Used for creating Element type specific lists.
hasOriginalElementList <R hasElementList Relation for element containing element lists. Stores the order of the all the child elements.
hasReference <R L0.IsRelatedTo Base relation for object references (converted ID references)
hasExternalReference <R L0.IsWeaklyRelatedTo Relation for references between data imported from different files. Note: external references must be created with post process functions, since schema conversion itself is not able to resolve references between different imports.


XML uses three types of attributes, Atomic, List, and Union. Current XML Schema conversion support only Atomic attributes.

XML datatype Simantics Notes
Atomic Supported
List Not Supported
Union Not supported

Primitive attributes are converted to Layer0 literals. List of primitive datatypes and respective literal types is:

XML datatype Simantics Notes
string L0.String
boolean L0.Boolean
decimal L0.Double
float L0.Float
double L0.Double
time L0.String
date L0.String
anyUri L0.Uri

Other built-in datatypes are converted to Layer0 literal types as well:

XML datatype Simantics Notes
normalizedString L0.String
token L0.String
ID L0.String ID attributes use XML.hasID property relation. An element is expected to have only one attribute with ID type.
IDREF L0.String
integer L0.Integer
nonPositiveInteger L0.Integer
negativeInteger L0.Integer
long L0.Long
int L0.Integer
short L0.Integer
byte L0.Byte
nonNegativeInteger L0.Integer
unsignedLong L0.Long
unsignedShort L0.Integer
unsignedByte L0.Byte
positiveInteger L0.Integer

XML schema allows defining new attribute types with constraining facets. Constraining facets are not currently supported.

XML Constraining facets Simantics Notes

In addition, individual attributes can be converted to a single array with Attribute Composition rule. Supported array datatypes are:

Conversion configuration Simantics
doubleArray L0.DoubleArray
stringArray L0.StringArray


Type definitions


XML schema allows SimpleTypes to be used as Element types for elements without child elements or as attribute types. When simpleType is used as attributes, the type will be converted to functional property relation:

<xsd:simpleType name="LengthUnitsType">
  <xsd:restriction base="xsd:NMTOKEN">
    <xsd:enumeration value="mm"/></xsd:restriction>
<xsd:element name="UnitsOfMeasure">
    <xsd:documentation>These are from …</xsd:documentation>
    <xsd:attribute name="Distance" type="LengthUnitsType" default="Millimetre">
PRO.hasLengthUnitsType <R PRO.XML.hasAttribute : L0.FunctionalRelation
   --> L0.String

PRO.hasUnitsOfMeasure <R PRO.XML.hasElement
PRO.hasUnitsOfMeasureList <R PRO.XML.hasElementList
PRO.UnitsOfMeasure <T PRO.XML.Element
PRO.UnitsOfMeasure.hasDistance <R PRO.XML.hasAttribute: L0.FunctionalRelation
   <R PRO.hasLengthUnitsType

When simpleType is used as definition of Element, the definition is converted to inheritance from the base literal type. In the following example, Knot elements xsd:double base is converted to inheritance to L0.Double:

<xsd:element name="Knot" maxOccurs="unbounded">
    <xsd:restriction base="xsd:double">
      <xsd:minInclusive value="0.0"/>
PRO.ComplexTypes.hasKnots.Knot <R PRO.XML.hasElement
PRO.ComplexTypes.hasKnots.KnotList <R PRO.XML.hasElementList
PRO.ComplexTypes.Knots.Knot <T PRO.XML.Element <T L0.Double


Schema conversion creates hard-coded ComplexType entity as a base type for ComplexTypes.

PRO.XML.ComplexType <T L0.Entity

ComplexTypes that are defined in the input schema are converted to L0.Entities, which inherit the hard-coded ComplexType, and are put into “ComplexTypes” library. Conversion also generates ComplexType specific generic relation for composition, and another relation for lists. Particles of a ComplexType are converted to ComplexType and particle specific relations inheriting the particle type related relation. Also, Attributes of the ComplexType are converted to the ComplexType and Attribute specific relations. For example, ComplexType “PlantItem” is converted to “ComplexTypes.PlantItem” entity, it has a “ComplexTypes.hasPlantItem” composition relation, and “ComplexTypes.hasPlantItemList” relation for lists. “ID” attribute is converted to “ComplexTypes.PlantItem.hasID” functional relation, and choice particle “Presentation” is converted to “ComplexTypes.PlantItem.hasPresentation” relation.

<xsd:complexType name="PlantItem">
  <xsd:choice minOccurs="0" maxOccurs="unbounded">
    <xsd:element ref="Presentation"/>
    <xsd:element ref="Extent"/><xsd:element name="ModelNumber" type="xsd:string"/></xsd:choice>
  <xsd:attribute name="ID" type="xsd:ID" use="required"/>
  <xsd:attribute name="TagName" type="xsd:string"/><xsd:attribute name="ComponentType">
    <xsd:restriction base="xsd:NMTOKEN">
      <xsd:enumeration value="Normal"/>
      <xsd:enumeration value="Explicit"/>
      <xsd:enumeration value="Parametric"/>
PRO.ComplexTypes.PlantItem <T PRO.XML.ComplexType
PRO.ComplexTypes.hasPlantItem <R PRO.XML.hasComplexType
PRO.ComplexTypes.hasPlantItemList <R PRO.XML.hasElementList
   --> PRO.ComplexTypes.PlantItem
PRO.ComplexTypes.PlantItem.hasPresentation <R PRO.hasPresentation
   --> PRO.Presentation
PRO.ComplexTypes.PlantItem.hasExtent <R PRO.hasExtent
   --> PRO.Extent
PRO.ComplexTypes.PlantItem.hasID <R PRO.XML.hasAttribute: L0.FunctionalRelation
   --> L0.String
PRO.ComplexTypes.PlantItem.hasComponentType <R PRO.XML.hasAttribute: L0.FunctionalRelation
   --> L0.String


Element definitions are processed similarly to ComplexTypes, but the converted types are put directly into the ontology without any library. Hence, Element “PlantModel” is converted to “PlantModel” entity.

<xsd:element name="PlantModel">
      <xsd:element ref="PlantInformation"/>
      <xsd:element ref="Extent"/>
      <xsd:any namespace="##targetNamespace" maxOccurs="unbounded"/>
PRO.hasPlantModel <R PRO.XML.hasElement
PRO.hasPlantModelList <R PRO.XML.hasElementList
PRO.PlantModel <T PRO.XML.Element
PRO.PlantModel.hasPlantInformation <R PRO.hasPlantInformation
   --> PRO.PlantInformation
PRO.PlantModel.hasExtent <R PRO.hasExtent
   --> PRO.Extent

When Element definition is defined with ComplexContent, ComplexContent’s extension’s base is converted to L0.Inheritance relation between the types. For example “Equpiment” Element has “PlantItem” as a base extension, so “Equipment” entity is inherited from “PlantItem” entity.

<xsd:element name="Equipment">
      <xsd:extension base="PlantItem">
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
          <xsd:element ref="Discipline" minOccurs="0"/>
          <xsd:element ref="MinimumDesignPressure"/><xsd:element ref="Equipment"/></xsd:choice>
        <xsd:attribute name="ProcessArea" type="xsd:string"/>
        <xsd:attribute name="Purpose" type="xsd:string"/>
PRO.hasEquipment <R PRO.XML.hasElement
PRO.hasEquipmentList <R PRO.XML.hasElementList
PRO.Equipment <T PRO.XML.Element <T PRO.PlantItem
PRO.Equipment.hasProcessArea <R PRO.XML.hasAttribute: L0.FunctionalRelation
   --> L0.String
PRO.Equipment.hasPurpose <R PRO.XML.hasAttribute: L0.FunctionalRelation
   --> L0.String
PRO.Equipment.hasDiscipline <R PRO.hasDiscipline
   --> PRO.Discipline
PRO.Equipment.hasMinimumDesignPressure <R PRO.hasMinimumDesignPressure
   --> PRO.MinimumDesignPressure
PRO.Equipment.hasEquipment <R PRO.hasEquipment
   --> PRO.Equipment

Indicators (choice, sequence, all)

When Indicators have maxOccurs larger than 1, relations generated according to particles have no multiplicity restrictions (ass all previous examples are defined). When indicator is choice with maxOccurs=1 (default value for maxOccurs), the particle relations is expected to refer to only one object that conforms to one of the specified types. For example, Element “TrimmedCurve” has choice indicator with 4 elements (“Circle”, “PCircle”, “Ellipse”, “PEllipse), and that choice is converted to “TrimmedCurve.hasCircleOrPCircleOrEllipseOrPEllipse” relation.

<xsd:element name="TrimmedCurve" substitutionGroup="Curve">
      <xsd:extension base="Curve">
            <xsd:element ref="Circle"/>
            <xsd:element ref="PCircle"/>
            <xsd:element ref="Ellipse"/>
            <xsd:element ref="PEllipse"/>
          <xsd:element ref="GenericAttributes" minOccurs="0"/>
        <xsd:attribute name="StartAngle" type="xsd:double" use="required"/>
        <xsd:attribute name="EndAngle" type="xsd:double" use="required"/>
PRO.hasTrimmedCurve <R PRO.XML.hasElement
PRO.hasTrimmedCurveList <R PRO.XML.hasElementList
PRO.TrimmedCurve <T PRO.XML.Element <T PRO.Curve
PRO.TrimmedCurve.hasStartAngle <R PRO.XML.hasAttribute: L0.FunctionalRelation
   --> L0.Double
PRO.TrimmedCurve.hasEndAngle <R PRO.XML.hasAttribute: L0.FunctionalRelation
   --> L0.Double
PRO.TrimmedCurve.hasCircleOrPCircleOrEllipseOrPEllipse <R PRO.hasCircle <R PRO.hasPCircle <R PRO.hasEllipse <R PRO.hasPEllipse
   --> PRO.Circle
   --> PRO.PCircle
   --> PRO.Ellipse
   --> PRO.PEllipse
PRO.TrimmedCurve.hasGenericAttributes <R PRO.hasGenericAttributes
   --> PRO.GenericAttributes

Note that Model Group definitions are not currently supported!

Customization via configuration

Attribute composition

Attribute composition rule allows converting separate attributes into one array. For example, following rule:

<AttributeComposition Name="XYZ" Type = "doubleArray">
  <Attribute Name="X" Type ="double"/>
  <Attribute Name="Y" Type ="double"/>
  <Attribute Name="Z" Type ="double"/>

causes “X”, “Y” and “Z” double attributes in “Coordinate” Element definition

<xsd:element name="Coordinate">
    <xsd:attribute name="X" type="xsd:double" use="required"/>
    <xsd:attribute name="Y" type="xsd:double" use="required"/>
    <xsd:attribute name="Z" type="xsd:double"/>

to be converted to “XYZ” double array:

PRO.Coordinate <T PRO.XML.Element
PRO.Coordinate.hasXYZ <R PRO.XML.hasAttribute: L0.FunctionalRelation
   --> L0.DoubleArray

ID references

Referencing other XML elements is usually done using element IDs. Using ID Provider and ID Reference rules allows converting these references to statements in Simantics DB. ID Provider rule is used for retrieving the ID from referred objects. The rule does not affect the generated ontology.

  <ComplexType Name = "PlantItem"/>
  <Attribute Name="ID" Type ="string"/>

ID Reference rule is used for objects that use ID references. ID Source tells which attribute is used to refer another Element, and Reference defines the name of the relation. With the following rule:

  <Element Name ="Connection"/>
  <IDSource Name="ToID" Type ="string"/>
  <Reference Name="ToIDRef" Type ="ref"/>

“Connection” element definition’s “ToID” reference is converted to ToIDRef relation.

<xsd:element name="Connection">
    <xsd:attribute name="ToID" type="xsd:string"/></xsd:complexType>

The original attribute is kept, so that if ID reference cannot be located, the information about the reference still exists.

PRO.Connection <T PRO.XML.Element
PRO.Connection.hasToID <R PRO.XML.hasAttribute: L0.FunctionalRelation
   --> L0.String
PRO.Connection.ToIDRef <R PRO.XML.hasReference

In imported data, the reference statement will point to referred Element, if the parser is able to locate a Element with the given ID.

Predicate Object Graph
Basic information
InstanceOf Connection DB
Is Related To
hasToID V_02_N6 (edit) DB
ToIDRef $412442 : (Nozzle) DB
Other statements
hasConnection/Inverse $416145 : (PipingNetworkSegment) DB

Ordered child

Ordered child rule allows storing the original order of the elements into lists. The rules either force the creating of the lists (used when the schema is interpreted to be indifferent of the order), or disabling the list generation. Currently the rule hat two types, original and child. An original type rule sets if all the child elements are out into “OriginalElementList”. An child rule sets if the child elements are added to type specific lists.

<OrderedChild Type="original" Value="disable">
  <ComplexType Name = "PlantItem"/>
<OrderedChild Type="child" Value="disable">
  <ComplexType Name = "PlantItem"/>

Unrecognized child elements

Unrecognized child element rule allows processing XML files that do not conform to given schema, and use different element names. In practice, the rule allows injecting Java code to generated parser classes. The code is put into method, which signature is:

public void configureChild(WriteGraph graph, Deque<Element> parents, Element element, Element child) throws DatabaseException

The method is called with ”element” as the element, which conforms to given type in the rule’s configuration, and ”child” is the child element, that could not be recognized. The following example is used for handling incorrect files, which have replaced element name with the contents of attribute “name”.

  <Element Name ="GenericAttributes"/>
  // Some commercial software do not handle GenericAttribute elements properly:
  // they use "Name" attribute's value as element's name.
  GenericAttribute ga = new GenericAttribute();
  java.util.List&lt;Attribute&gt; attributes = new java.util.ArrayList&lt;Attribute&gt;();
  attributes.add(new Attribute("Name", "Name", "", child.getQName()));
  Element newChild = new Element("", "", "GenericAttribute", attributes);
  Resource res = ga.create(graph, newChild);
  if (res != null) {
    ga.configure(graph, parents, newChild);
    connectChild(graph, element, newChild);

An example of incorrect file:

<GenericAttributes Number="28" Set="Values">
  <Assembly Format="string" Value="5. Auxiliary Steam System" />
  <Bendingradiusrtube Format="double" Value="0" Units="mm" ComosUnits="mm M01.15" />
  <CostCode Format="double" Value="607" />

When the content should be:

<GenericAttributes Number="28" Set="Values">
  <GenericAttribute Name="Assembly" Format="string" Value="5. Auxiliary Steam System" />
  <GenericAttribute Name="Bendingradiusrtube" Format="double" Value="0" Units="mm“ />
  <GenericAttribute Name="CostCode" Format="double" Value="607" />


  1. W3C XML Schema definition language (XSD) 1.1 Part 1: Structures http://www.w3.org/TR/xmlschema11-1/
  2. W3C XML Schema definition language (XSD) 1.1 Part 2: Datatypes http://www.w3.org/TR/xmlschema11-2/
  3. Layer0 specification http://dev.simantics.org/images/c/c8/Layer0.pdf