130 likes | 140 Views
Model based schema. UML to XSD binding . Start with UML model Generate XMI from UML Define UML to XSD binding Implement binding as XSLT script Run script. Sample UML. Mapping “methodology”. Simple: as “1-1” as possible Preserve semantics Attributes owned by class
E N D
Model based schema Gerard Lemson
UML to XSD binding • Start with UML model • Generate XMI from UML • Define UML to XSD binding • Implement binding as XSLT script • Run script Gerard Lemson
Sample UML Gerard Lemson
Mapping “methodology” • Simple: as “1-1” as possible • Preserve semantics • Attributes owned by class • Children in parent-child composition relation owned by parent/container • Focus on type definitions, complexType-s mainly • Valid documents (global elements) defined with respect to, but separate from the type definitions • Default document: contains an element definition under the root for each “root-entity-class”. • Possibility of reuse of schema type definitions in different special purpose document definitions. Gerard Lemson
Mapping: packages • Package -> (target)namespace, in own file • Dependency -> import of dependent namespace and file <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="urn://xml.registry.gavo.org/aas" elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.1" xmlns:aas="urn://xml.domainmodel.gavo.org/aas" xmlns:base="urn://xml.domainmodel.gavo.org/" xmlns:cees="urn://xml.domainmodel.gavo.org/cees"> ... <xsd:importnamespace="urn://xml.registry.gavo.org/cees" schemaLocation="./cees.xsd" /> Gerard Lemson
Mapping Classes • Every class -> globally defined complexType • isAbstract -> abstract=“true” • Attribute -> element of simplish-type, either built-in, or also generated <xsd:complexType name="A" abstract="true"> <xsd:complexContent> <xsd:extension base="base:DataObject"> <xsd:sequence> <xsd:elementname="id" type="xsd:integer" /> <xsd:elementname="description" type="xsd:string"/> <xsd:elementname="f" type="aas:F" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> Gerard Lemson
Mapping Classes II • Inheritance -> extension of base class <xsd:complexType name="B"> <xsd:complexContent> <xsd:extension base="aas:A"> <xsd:sequence> <xsd:elementname="data" type="xsd:double" /> <xsd:elementname="c" type="cees:CProxy" /> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> Gerard Lemson
Mapping Associations I • Parent-child relationship • Composition -> element of appropriate complexType <xsd:complexType name="C"> <xsd:complexContent> <xsd:extension base="base:DataObject"> <xsd:sequence> <xsd:elementname="name" type="xsd:string"/> <xsd:elementname="dees" type="cees:D" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> Gerard Lemson
Mapping associations II • “Owned references” -> element of appropriate type <xsd:complexType name="A" abstract="true"> <xsd:complexContent> <xsd:extension base="base:DataObject"> <xsd:sequence> <xsd:elementname="id" type="xsd:integer" /> <xsd:elementname="description" type="xsd:string" /> <xsd:elementname="f" type="aas:F" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> Gerard Lemson
Mapping associations III • Problem: shared references (also aggregations), many-to-1/many relations • Does one want to replicate elements that are shared ? • Multiple B-s can reference same C. • Solutions: • Don‘t care, map ala composition, with cardinality maxOccurs=“0” • Use ID/IDREF or KEY/KEYREF declarations. Requires the C to exist in same document, possibly completely, i.e. containing all substructure. • Use explicit “proxy ” element, for example using a GUID (IVOA identifier?), which can/must be resolved before the referenced object can be obtained.This is the most tricky thing I think about XML schemas, how to properly embed the semantics of the shared association into a logical schema design. Gerard Lemson
Default Document • Root entity classes map also to an element in a document, but in a separate schema doc, depending on the type defining schema documents. <?xml version="1.0" encoding="UTF-8" ?> <xsd:schematargetNamespace="urn://xml.registry.gavo.org/doc"... xmlns:doc="urn://xml.registry.gavo.org/doc" xmlns:cees="urn://xml.registry.gavo.org/cees" xmlns:aas="urn://xml.registry.gavo.org/aas"> <xsd:importnamespace="urn://xml.registry.gavo.org/cees" schemaLocation="./cees.xsd" /> <xsd:importnamespace="urn://xml.registry.gavo.org/aas" schemaLocation="./aas.xsd" /> <xsd:element name="sample"> <xsd:complexType><xsd:sequence> <xsd:elementname="c" type="cees:C" minOccurs="0" maxOccurs="unbounded" /> <xsd:elementname="a" type="aas:A" minOccurs="0" maxOccurs="unbounded"/> <xsd:elementname="b" type="aas:B" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence></xsd:complexType> </xsd:element> </xsd:schema> Gerard Lemson
Comments • Single inheritance mapping, only extension, no substitutionGroupRequires xsi:type construct (next slide) to indicate which precise class is used. • No element ref construct. • No global elements for attributes and contained classes. • Analogy to Java binding : • Complex type <=> class • Typed <element> declarations <=> Fields in class definition • Default document <=> a main method using the classes. • Global elements <=> variable declarations local to main method • Can support a more involved special purpose document to/from the “official” default registry document using XSLT scripts for example (view concept). • See also: http://www.xml.com/pub/a/2002/08/07/wxs_uml.html and others • Probably more … Gerard Lemson
xsi:type • xsi:type=‘’ construct from the xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” in document required to indicate precise class: <?xml version="1.0" encoding="UTF-8" ?> <doc:sample xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:doc="urn://xml.registry.gavo.org/doc" xmlns:cees="urn://xml.registry.gavo.org/cees"> <doc:c> <name>a C</name> <d xsi:type="cees:D1"> <name>a D1</name> </d> <d xsi:type="cees:D2"> <identifier>a D2</identifier> </d> </doc:c> </doc:sample> Gerard Lemson