XML Schema Conversion - Revision history

Marko Luukkainen: /* Unrecognized child elements */

2016-03-17T12:22:25Z

Unrecognized child elements

← Older revision		Revision as of 12:22, 17 March 2016
Line 524:		Line 524:

	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”.		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”.
	<~~pre~~>		<source lang="xml">
	<UnrecognizedChildElement>		<UnrecognizedChildElement>
	<Element Name ="GenericAttributes"/>		<Element Name ="GenericAttributes"/>
Line 546:		Line 546:
	</JavaMethod>		</JavaMethod>
	</UnrecognizedChildElement>		</UnrecognizedChildElement>
	</~~pre~~>		</source>
	An example of incorrect file:		An example of incorrect file:
	<~~pre~~>		<source lang="xml">
	<GenericAttributes Number="28" Set="Values">		<GenericAttributes Number="28" Set="Values">
	<Assembly Format="string" Value="5. Auxiliary Steam System" />		<Assembly Format="string" Value="5. Auxiliary Steam System" />
	<Bendingradiusrtube Format="double" Value="0" Units="mm" ComosUnits="mm M01.15" />		<Bendingradiusrtube Format="double" Value="0" Units="mm" ComosUnits="mm M01.15" />
	<CostCode Format="double" Value="607" />		<CostCode Format="double" Value="607" />
	</~~pre~~>		</source>
	When the content should be:		When the content should be:
	<~~pre~~>		<source lang="xml">
	<GenericAttributes Number="28" Set="Values">		<GenericAttributes Number="28" Set="Values">
	<GenericAttribute Name="Assembly" Format="string" Value="5. Auxiliary Steam System" />		<GenericAttribute Name="Assembly" Format="string" Value="5. Auxiliary Steam System" />
	<GenericAttribute Name="Bendingradiusrtube" Format="double" Value="0" Units="mm“ />		<GenericAttribute Name="Bendingradiusrtube" Format="double" Value="0" Units="mm“ />
	<GenericAttribute Name="CostCode" Format="double" Value="607" />		<GenericAttribute Name="CostCode" Format="double" Value="607" />
	</~~pre~~>		</source>

	=References=		=References=

Marko Luukkainen: /* Ordered child */

2016-03-17T12:21:48Z

Ordered child

← Older revision		Revision as of 12:21, 17 March 2016
Line 506:		Line 506:
	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.		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.		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.
	<~~pre~~>		<source lang="xml">
	<OrderedChild Type="original" Value="disable">		<OrderedChild Type="original" Value="disable">
	<ComplexType Name = "PlantItem"/>		<ComplexType Name = "PlantItem"/>
Line 514:		Line 514:
	<ComplexType Name = "PlantItem"/>		<ComplexType Name = "PlantItem"/>
	</OrderedChild>		</OrderedChild>
	</~~pre~~>		</source>

	==Unrecognized child elements==		==Unrecognized child elements==

Marko Luukkainen: /* ID references */

2016-03-17T12:21:25Z

ID references

← Older revision		Revision as of 12:21, 17 March 2016
Line 443:		Line 443:
	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.		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.		ID Provider rule is used for retrieving the ID from referred objects. The rule does not affect the generated ontology.
	<~~pre~~>		<source lang="xml">
	<IDProvider>		<IDProvider>
	<ComplexType Name = "PlantItem"/>		<ComplexType Name = "PlantItem"/>
	<Attribute Name="ID" Type ="string"/>		<Attribute Name="ID" Type ="string"/>
	</IDProvider>		</IDProvider>
	</~~pre~~>		</source>
	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:		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:
	<~~pre~~>		<source lang="xml">
	<IDReference>		<IDReference>
	<Element Name ="Connection"/>		<Element Name ="Connection"/>
Line 456:		Line 456:
	<Reference Name="ToIDRef" Type ="ref"/>		<Reference Name="ToIDRef" Type ="ref"/>
	</IDReference>		</IDReference>
	</~~pre~~>		</source>
	“Connection” element definition’s “ToID” reference is converted to ToIDRef relation.		“Connection” element definition’s “ToID” reference is converted to ToIDRef relation.
	<~~pre~~>		<source lang="xml">
	<xsd:element name="Connection">		<xsd:element name="Connection">
	<xsd:complexType>		<xsd:complexType>
Line 465:		Line 465:
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</~~pre~~>		</source>
	The original attribute is kept, so that if ID reference cannot be located, the information about the reference still exists.		The original attribute is kept, so that if ID reference cannot be located, the information about the reference still exists.
	<pre>		<pre>

Marko Luukkainen: /* Attribute composition */

2016-03-17T12:20:28Z

Attribute composition

← Older revision		Revision as of 12:20, 17 March 2016
Line 415:		Line 415:

	Attribute composition rule allows converting separate attributes into one array. For example, following rule:		Attribute composition rule allows converting separate attributes into one array. For example, following rule:
	<~~pre~~>		<source lang="xml">
	<AttributeComposition Name="XYZ" Type = "doubleArray">		<AttributeComposition Name="XYZ" Type = "doubleArray">
	<Attribute Name="X" Type ="double"/>		<Attribute Name="X" Type ="double"/>
Line 421:		Line 421:
	<Attribute Name="Z" Type ="double"/>		<Attribute Name="Z" Type ="double"/>
	</AttributeComposition>		</AttributeComposition>
	</~~pre~~>		</source>
	causes “X”, “Y” and “Z” double attributes in “Coordinate” Element definition		causes “X”, “Y” and “Z” double attributes in “Coordinate” Element definition
	<~~pre~~>		<source lang="xml">
	<xsd:element name="Coordinate">		<xsd:element name="Coordinate">
	<xsd:complexType>		<xsd:complexType>
Line 431:		Line 431:
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</~~pre~~>		</source>
	to be converted to “XYZ” double array:		to be converted to “XYZ” double array:
	<pre>		<pre>

Marko Luukkainen: /* Indicators (choice, sequence, all) */

2016-03-17T12:19:37Z

Indicators (choice, sequence, all)

← Older revision		Revision as of 12:19, 17 March 2016
Line 371:		Line 371:
	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.		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.		For example, Element “TrimmedCurve” has choice indicator with 4 elements (“Circle”, “PCircle”, “Ellipse”, “PEllipse), and that choice is converted to “TrimmedCurve.hasCircleOrPCircleOrEllipseOrPEllipse” relation.
	<~~pre~~>		<source lang="xml">
	<xsd:element name="TrimmedCurve" substitutionGroup="Curve">		<xsd:element name="TrimmedCurve" substitutionGroup="Curve">
	<xsd:complexType>		<xsd:complexType>
Line 391:		Line 391:
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</~~pre~~>		</source>
	<pre>		<pre>
	PRO.hasTrimmedCurve <R PRO.XML.hasElement		PRO.hasTrimmedCurve <R PRO.XML.hasElement

Marko Luukkainen: /* Element */

2016-03-17T12:19:18Z

Element

← Older revision		Revision as of 12:19, 17 March 2016
Line 310:		Line 310:
	==Element==		==Element==
	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.		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.
	<~~pre~~>		<source lang="xml">
	<xsd:element name="PlantModel">		<xsd:element name="PlantModel">
	<xsd:complexType>		<xsd:complexType>
Line 320:		Line 320:
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</~~pre~~>		</source>
	<pre>		<pre>
	PRO.hasPlantModel <R PRO.XML.hasElement		PRO.hasPlantModel <R PRO.XML.hasElement
Line 331:		Line 331:
	</pre>		</pre>
	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.		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.
	<~~pre~~>		<source lang="xml">
	<xsd:element name="Equipment">		<xsd:element name="Equipment">
	<xsd:complexType>		<xsd:complexType>
Line 349:		Line 349:
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>		</xsd:element>
	</~~pre~~>		</source>
	<pre>		<pre>
	PRO.hasEquipment <R PRO.XML.hasElement		PRO.hasEquipment <R PRO.XML.hasElement
Line 367:		Line 367:
	…		…
	</pre>		</pre>

	==Indicators (choice, sequence, all)==		==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.		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.

Marko Luukkainen: /* ComplexType */

2016-03-17T12:18:46Z

ComplexType

← Older revision		Revision as of 12:18, 17 March 2016
Line 266:		Line 266:
	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.		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.		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.
	<~~pre~~>		<source lang="xml">
	<xsd:complexType name="PlantItem">		<xsd:complexType name="PlantItem">
	<xsd:choice minOccurs="0" maxOccurs="unbounded">		<xsd:choice minOccurs="0" maxOccurs="unbounded">
Line 289:		Line 289:
	…		…
	</xsd:complexType>		</xsd:complexType>
	</~~pre~~>		</source>

	<pre>		<pre>
Line 307:		Line 307:
	--> L0.String		--> L0.String
	</pre>		</pre>

	==Element==		==Element==
	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.		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.

Marko Luukkainen: /* SimpleType */

2016-03-17T12:18:12Z

SimpleType

← Older revision		Revision as of 12:18, 17 March 2016
Line 215:		Line 215:
	XML schema allows SimpleTypes to be used as Element types for elements without child elements or as attribute types.		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:		When simpleType is used as attributes, the type will be converted to functional property relation:
	<~~pre~~>		<source lang="xml">
	<xsd:simpleType name="LengthUnitsType">		<xsd:simpleType name="LengthUnitsType">
	<xsd:restriction base="xsd:NMTOKEN">		<xsd:restriction base="xsd:NMTOKEN">
Line 230:		Line 230:
	<xsd:attribute name="Distance" type="LengthUnitsType" default="Millimetre">		<xsd:attribute name="Distance" type="LengthUnitsType" default="Millimetre">
	</xsd:attribute>		</xsd:attribute>
	</~~pre~~>		</source>
	<pre>		<pre>
	PRO.hasLengthUnitsType <R PRO.XML.hasAttribute : L0.FunctionalRelation		PRO.hasLengthUnitsType <R PRO.XML.hasAttribute : L0.FunctionalRelation
Line 242:		Line 242:
	</pre>		</pre>
	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:		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:
	<~~pre~~>		<source lang="xml">
	<xsd:element name="Knot" maxOccurs="unbounded">		<xsd:element name="Knot" maxOccurs="unbounded">
	<xsd:simpleType>		<xsd:simpleType>
Line 250:		Line 250:
	</xsd:simpleType>		</xsd:simpleType>
	</xsd:element>		</xsd:element>
	</~~pre~~>		</source>
	<pre>		<pre>
	PRO.ComplexTypes.hasKnots.Knot <R PRO.XML.hasElement		PRO.ComplexTypes.hasKnots.Knot <R PRO.XML.hasElement
Line 256:		Line 256:
	PRO.ComplexTypes.Knots.Knot <T PRO.XML.Element <T L0.Double		PRO.ComplexTypes.Knots.Knot <T PRO.XML.Element <T L0.Double
	</pre>		</pre>

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

Marko Luukkainen: /* ID references */

2016-03-17T12:01:43Z

ID references

← Older revision		Revision as of 12:01, 17 March 2016
Line 472:		Line 472:
	In imported data, the reference statement will point to referred Element, if the parser is able to locate a Element with the given ID.		In imported data, the reference statement will point to referred Element, if the parser is able to locate a Element with the given ID.

	{\|class="wikitable" style="text-align: center; color: green;"		{\|class="wikitable" style="text-align: center; color: white; background-color:green;"
	!Predicate		\|Predicate
	!Object		\|Object
	!Graph		\|Graph
	\|-		\|- style="text-align: center; color: white; background-color:blue;"
	\|Basic information		\|colspan="3"\|Basic information
	\|-		\|- style="color: blue; background-color:#ffffcc;"
	\|InstanceOf		\|InstanceOf
	\|Connection		\|Connection
	\|DB		\|DB
	\|-		\|-style="text-align: center; color: white; background-color:blue;"
	\|Is Related To		\|colspan="3"\|Is Related To
	\|-		\|- style="color: blue; background-color:#ffffcc;"
	\|hasToID		\|hasToID
	\|V_02_N6 (edit)		\|V_02_N6 (edit)
	\|DB		\|DB
	\|-		\|- style="color: blue; background-color:#ffffcc;"
	\|ToIDRef		\|ToIDRef
	\|$412442 : (Nozzle)		\|$412442 : (Nozzle)
	\|DB		\|DB
	\|-		\|-style="text-align: center; color: white; background-color:blue;"
	\|Other statements		\|colspan="3"\|Other statements
	\|-		\|- style="color: blue; background-color:#ffffcc;"
	\|hasConnection/Inverse		\|hasConnection/Inverse
	\|$416145 : (PipingNetworkSegment)		\|$416145 : (PipingNetworkSegment)

Marko Luukkainen at 11:45, 17 March 2016

2016-03-17T11:45:21Z

Show changes