Skip to content

Data Model

Jump to bottom
Daniel Adlkofer edited this page Feb 10, 2023 · 5 revisions

Data Models define the structure of data. A main purpose is to standardize specific data structures, which are determined aloofly the Data Type-based XMOM data structures of the Xyna Factory.

Typically the Xyna Factory uses Data Models to simplify the communication with devices via Workflows. For this reason there are several Data Model types that can be imported into and used by the Xyna Factory. Data Models can be managed via CLI.

Table of Contents

Import a Data Model

To import a new Data Model use the CLI command ./xynafactory.sh '''importdatamodel''' -datamodeltype <arg> [-files <args>] [-importParameters <args>].

Via ./xynafactory.sh '''listdatamodeltypes''' [-lang <arg>] you can list the registered Data Model types. The files will be imported sequentially in the specified order. Each Data Model type has specific import parameters.

MIB and TR-069

Figure 1: Form to import an MIB Data Model
(A) upload an MIB file for import, (B) remove selected MIB file from import, (C) add base OID, (D) remove base OID, (E) import MIB

From an MIB or TR-069 file, a hierarchical Data Model will be created. There are the following import parameters:

  • basePath: Base path of generated types (optional, type=String, default="xdnc.model.mib")
  • baseTypeName: Base type of generated types (optional, type=String, default="xdnc.model.mib.MIBBaseModel")
  • information: Print informations (optional, type=EnumSet, default=ListMIBs, ModuleStatistics)
    • ListMIBs: not implemented yet
    • ModuleStatistics: not implemented yet
  • oids: OID restrictions to import partial mib, oids separated by whitespace (optional, type=List)
  • overwrite: Overwrites existing types (optional, type=Boolean, default=false)
  • noImport: No Import, only analysis of mibs (optional, type=Boolean, default=false)
  • versioning: Algorithm to extract version from MIB module (optional, type=Enum, default=CountRevisions)
    • CountRevisions: count of revisions
    • LastUpdated: timestamp of last revision

XSD

Figure 2: Form to import an XSD Data Model
(A) upload an XSD file for import, (B) remove selected XSD file from import, (C) configure Data Type path, (D) specify import destination, (E) simulate import, (F) import MIB

From an XSD, a Data Type will be created for each XSD type. These Data Types can be imported to an existing Workspace or (if Modularization is supported) be part of a new Application, which can be used as Requirement.

There are the following import parameters:

  • name: Unique Name of the Data Model. Will be part of the type path of the generated Data Types. (mandatory, type=String) Syntax: name="<myName>"
  • workspaces: workspaces to generate or copy into (optional, type=List, default=default workspace) Syntax: workspaces=<myWS1>,<myWS2>...
  • basePath: Base path of generated types (optional, type=String, default="xdnc.model.xsd") Syntax: basePath=<myBasePath>
  • pathCustomization: Customization of xmom-path, e.g. '/#basepath/#name/#nshost/#nspath' (optional, type=EnumCombination, default=/#basepath/#name/#nshost/#nspath) Syntax: pathCustomization='/<my.path>/<name>/<myhost>/<revhost>/<noversion>/<prefix>/<suffix>'
    • basepath: Basepath as in parameter 'basePath'
    • name: Name of Data Model as in parameter 'name'
    • nshost: Host from XSD-namespace
    • nsrevhost: Host from XSD-namespace in reverse order
    • nspath: Path from XSD-namespace
    • nspath_noversion: Path from XSD-namespace without versions numbers
    • type_prefix: Prefix from type name (till first uppercase letter)
    • type_suffix: Suffix from type name (from last uppercase letter)
  • labelCustomization: Customization of labels (optional, type=EnumMap, default=)
    • suffixForAttribute: Labels for attributes get this suffix Syntax: labelCustomization=suffixForAttribute=<mySuffix>
    • suffixForOptional: Optional elements get this suffix Syntax: labelCustomization=suffixForAttribute=<mySuffixForAttributes>
    • uppercaseFirstLetter: Label starts with uppercase letter Syntax: labelCustomization=suffixForAttribute=[true]|[false]
  • overwrite: Overwrites an existing data model with the same name (optional, type=Boolean, default=false) Syntax: overwrite=[true]|[false]
  • overwriteDataTypes: Overwrites existing data types (optional, type=Boolean, default=false) Syntax: overwriteDataTypes=[true]|[false]
  • noImport: No Import, only analysis of xsds (optional, type=Boolean, default=false) noImport=[true]|[false]
  • information: Print informations (optional, type=EnumSet, default=ListXSDs, ListNamespaces, ListDatatypes, ListDatatypeTree) Syntax: information='[ListXSDs], [ListNamespaces], [ListDatatypes], [ListDatatypeTree]'
    • ListXSDs: List all used XSDs
    • ListNamespaces: List namespaces and their generated xmom paths
    • ListDatatypes: List all generated datatypes
    • ListDatatypeTree: List all generated datatypes as inheritance tree
  • generationOptions: Options to customize the type generation (optional, type=EnumMap, default=) Syntax: generationOptions=expandChoice=[true]|[false] namedSimpleTypes=[true]|[false] includeHiddenTypes=[true]|[false]
    • expandChoice: Expand choice to many optional member variables
    • namedSimpleTypes: Defined simple types will be generated as objects
    • includeHiddenTypes: Include types not accesible from root elements
  • distributeToWorkspaces: Distribute generated types into workspaces (optional, type=Boolean, default=false) Syntax: distributeToWorkspaces=[true]|[false]
  • xmlDocumentPath: deprecated, now constant (optional, type=String, default="xfmg.xfctrl.datamodel.xsd")
  • baseTypeName: deprecated, now constant (optional, type=String, default="xdnc.model.xsd.XSDBaseModel")

Syntax example for CLI

The following shows a syntax example to illustrate the import of a xsd data model on the command line interface: ./xynafactory.sh importdatamodel -datamodeltype XSD -files /tmp/my.xsd -importParameters name=myModel workspaces=myWS1,myWS2 basePath="myBase" pathCustomization='/xprv.geko.xsd/GeKoAuftrag/myhost/revhost/noversion/prefix/suffix' labelCustomization=suffixForAttribute=suffix labelCustomization=suffixForOptional=opt_suffix labelCustomization=uppercaseFirstLetter=true overwrite=true overwriteDataTypes=true noImport=true information='ListXSDs, ListNamespaces' generationOptions=expandChoice=true generationOptions=namedSimpleTypes=true generationOptions=includeHiddenTypes=true distributeToWorkspaces=true

Not supported XSD Features

With XSDs, many different structures can be "conceived". Not all of these features are currently supported by the Xyna Factory during the import (for example, because it is not always possible to map them to the Xyna data model). Ideally, there is a workaround for unsupported features.

-Mixed ComplexType-

ComplexTypes can contain the attribute "mixed = true". Thus, e.g. the following structures are allowed in XML:

  1. <a1>123<a2>xx</a2>456</a1>
  2. <a1 attribut="x">123</a1>
The attribute "mixed" is currently not supported by Xyna.

The first of the above structures can not be mapped in the Xyna data model, so there is no workaround for this.

For the second structure a workaround is possible.

Before: 

<xs:element name="pac">
    <xs:complexType mixed="true">
        <xs:attribute name="order" use="required"/>
    </xs:complextype>
</xs:element>
After: 
<xs:element name="pac">
    <xs:complexType>
        <xs:simpleContent>
            <xs:extension base="xs:string">
                <xs:attribute name="order" use="required"/>
            </xs:extension>
        </xs:simplecontent>
    </xs:complextype>
</xs:element>

See Also

Clone this wiki locally