JOSIF Main Page | JOSIF Framework | TIP Soap Generator | TIP Soap Generator Mapping Rules - Part I
Terminology and Convention
Terminology
XSD: XML Schema Definition Language.
An entity type is called OC-enabled or ODisc-enabled, or ODel-enabled respectively if its tipClass:objectCreationNotification=YES, or tipClass:objectDiscoveryNotification=YES, or tipClass:objectDeletionNotification=YES.
An entity type is called AVC-enabled, if at least on of its (local or inherited) attribute or association end has tipAttribute:notificationDefinition=YES.
The terminologies are also applied to association classes.
Convention
For a given artifact (entity, datatype, exception, notification, association class), we call its corresponding XSD type with the naming pattern: artifact short name + 'XSD type'. For instance, the XSD type comes from the entity org.tmforum.tip.service.problem.ServiceProblem in SPM model is called ServiceProblem XSD type. Here we omit its namespace because we assume the namespace is already known according to an obvious mapping rule.
We call an xsd:element element of an XSD complex type as sub-element of the XSD complex type. It is different with global elements in XSD file.
Generic Mapping Rules
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
Mapping Rule for Namespace
Mapping Rule
Map a fully qualifed package name to namespace, the pattern of the namespace is
TIP Root Namespace + final part
where TIP Root Namespace is 'http://www.tmforum.org/xml/tip', and the final part of the namespace comes from final parts of the package (i.e. the part after ''org.tmforum.tip') by replace '.' with '/'.
Sample
For a package named 'org.tmforum.tip.cbe.test', the final parts of package name is '.cbe.test', the whole name space is 'http://www.tmforum.org/xml' + '/tip/cbe/test', that is 'http://www.tmforum.org/xml/tip/cbe/test'
Mapping Rule for Attributes, Association Ends, and Parameters
When an entity (or association class, exception, datatype, notification) artifact is mapped to XSD complex type, all its attributes are mapped to sub-elements of the XSD complex type.
An association artifact will not be mapped to XSD type. Instead, its navigable end will be mapped to XSD sub-element, and the enclosing XSD type of this sub-element is the image of the entity refered by its opposite end.
An attribute of an entity (or association class, exception, datatype, notification), a navigable end of an association, follow the same mapping rule as depicted in following table.
Similar mapping rules for parameters.
Example
You can find examples from sections about mapping rules of entities, association classes, notifications, datatypes, and operations.
Mapping Rule for Abstract Artifacts
Mapping Rule
Map abstract artifacts (entity, association class, exception, datatype, notification) to abstract XSD complex types.
Example
You can find examples from the sections about abstract entities, abstract datatypes, etc.
Mapping Rule for Inheritance
Map inheritance of artifacts (entity, datatype, association class, notification, exception, enumeration?) to extension of corresponding XSD types.
Note that in TIP models, multiple inheritance of artifacts is not allowed.
Mapping Rule for Extendability
Mapping Rule
All entity artifacts are automatically extendable. EntityBase has an attribute named extensionInfo and all entity XSD type inherits the attribute directly or indirectly.
We don't talk about extendability for Association classes.
All exception artifacts are extendable. The generator injects extensionInfo sub-element to ExceptionBase XSD type and all exception XSD type inherits it directly or indirectly.
The tipDatatype stereotype, which applies to datatypes and enumerations, has isExtendable property. If a datatype artifact has 'tipDatatype:isExtendable=true', it is extendable. The generator will inject extensionInfo sub-element to the XSD type of the datatype.
We don't talk about extendability for Enumeration artifact.
All notification artifacts are extendable. The generator injects extensionInfo sub-element to NotificationBase XSD type and all notification XSD type inherits the element directly or indirectly.
For an operation, if its tipOperation:isExtendable is 'True', the generator will inject extensionInfo sub-elemtn to both request and response messages (if any).
The structure of the extensionInfo sub-element is given here:
<xsd:element name="extensionInfo" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<p>A generic list of any type of elements. Used for vendor Extensions or loose element encapsulation from other namespaces.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Please refer to following mapping rules for specific information.
Extendability of Entity: TIP_Soap_Generator_Mapping_Rules_-_Part_I
Extendability of Datatype: TIP_Soap_Generator_Mapping_Rules_-_Part_III
Extendability of Exception: TIP_Soap_Generator_Mapping_Rules_-_Part_III
Extendability of Notification: TIP_Soap_Generator_Mapping_Rules_-_Part_III
Extendability of Enumeration: TIP_Soap_Generator_Mapping_Rules_-_Part_III
Extendability of Operation: TIP_Soap_Generator_Mapping_Rules_-_Part_IV
Mapping Rules for Packages
Mapping Rule for Package Name
Mapping Rule
For every package in TIP model projects, if it directly contains at least one artifact with one of following kinds, an XSD file will be generated and the file will contain XSD types corresponding to all direct children artifacts of the package (and more XSD types will possibly be generated):
Entity
Data Type
Enumeration
Exception
Association Class
Event
The targetNamespace of the XSD file is determined by the package name. (detail rule will be shown in following example)
Note: For mapping rules related with Session Facade artifacts, please refer to section 'Mapping Rules of Session Facade'.
Note: Typically, an association ends will be mapped to a sub-element of Entity XSD complex type. Please refer to section 'Associations and Association Classes'.
Example
In SPM model, the package org.tmforum.tip.service.problem contains following artifacts:
org.tmforum.tip.service.problem.ServiceProblem
The XSD file name corresponding to the package org.tmforum.tip.service.problem is spm_service_problem.xsd, where 'spm' is a model short name as defined in TIP_Soap_Generator.
The namespace corresponding to the package org.tmforum.tip.service.problem is http://www.tmforum.org/xml/tip/service/problem
Mapping Rules for Entities
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
- TIP_Soap_Generator_Mapping_Rules_-_Part_I
Map entity name to XSD type name
Mapping Rule
In tigerstripe model terminology, every artifact has a fully qualified name and a short name. For example, the entity org.tmforum.tip.cbe.problem.Problem has fully qualified name 'org.tmforum.tip.cbe.problem.Problem', has short name 'Problem'.
In XSD language, every complex type has namespace and has an attribute named 'name'. For example, in OSS/J Fault Management specification, in namespace http://ossj.org/xml/FaultManagement/v1-0, we have an entity named 'AlarmValue',
the value of its 'name' attribute is 'AlarmValue'.
<xsd:complexType name="AlarmValue">
<!-- content omitted -->
</xsd:complexType>
Every Entity artifact is mapped to two XSD complex types:
one XSD type for which the name is equal to the short name of the entity
one XSD type for which the name is equal to 'ArrayOf'+the short name of the entity (refer to example below). This kind of XSD types is needed since we need to represent the references and not just the cardinality alone.
The two XSD types are in the same namespace which is the image of the package name of the entity under the mapping rule specified in section TIP Soap Generator_Mapping_Rules
Note: The detailed definitions of these two complex types are determined by mapping rules specified in other sections.
Example
In SPM model, the entity org.tmforum.tip.cbe.problem.Problem is mapped to two XSD complex types: Problem and ArrayOfProblem, in namespace http://www.tmforum.org/xml/tip/cbe/problem
<xsd:complexType name="Problem" abstract="true">content omitted here</xsd:complexType> <xsd:complexType name="ArrayOfProblem">content omitted here</xsd:complexType>
tipClass: objectCreationNotification
Related to issue #14 in Mantis objectCreationNotification
Mapping Rule
For an entity artifact in a TIP model, tipClass:objectCreationNotification takes value from the set {YES,NO,NA}. If the value is NO or NA, nothing will be generated. If the value is YES (in this case, we can say that this entity is OC-enabled), an subtype of TIP Common ObjectCreationNotification (refer to ) and a global element with a payload of this subtype will be generated.
The name of the subtype is <EntityName>OCNotification, where the <EntityName> is short name of the entity, for example, for an entity named org.tmforum.tip.service.problem.ServiceProblem, <EntityName> is ServiceProblem, so the subtype name is ServiceProblemOCN. The subtype is in the same namespace with the entity, and its structure is:
<xsd:complexType name="<EntityName>OCN"> <xsd:complexContent> <xsd:extension base="<prefix of namespace of TIP Common notifications>:OCNotification"> <xsd:sequence> <xsd:element name="object" type="tns:<EntityName>" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType>
The name of the global element is <EntityName>OCN, where the <EntityName> is the short name of the entity with first character changed to lower case. For example, for an entity named org.tmforum.tip.service.problem.ServiceProblem, <EntityName> is serviceProblem, so the global element name is serviceProblemOCN. The element is in the same namespace with the entity and notification subtype, and its structure is:
<xsd:element name="<EntityName>OCN" type="tns:<EntityName>OCN">
<xsd:annotation>
<xsd:documentation>
Event that is sent if an <EntityName> instance has been created.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
Example (tipClass:objectCreationNotification=YES)
In TIP SPM model, the entity org.tmforum.tip.service.problem.ServiceProblem is OC-enabled. The entity is mapped to a XSD complex type named ServiceProblem in the namespace http://www.tmforum.org/xml/tip/service/problem. In the same namespace, a notification type and a global element is generated:
<xsd:complexType name="ServiceProblemOCN">
<xsd:complexContent>
<xsd:extension base="notifications:OCNotification">
<xsd:sequence>
<xsd:element name="object" type="tns:ServiceProblem" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="ServiceProblemOCN" type="tns:ServiceProblemOCN">
<xsd:annotation>
<xsd:documentation>
Event that is sent if an ServiceProblem instance has been created.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
Example (tipClass:objectCreationNotification=NO or NA)
also in TIP SPM model, the entity org.tmforum.tip.cbe.problem.TrackingRecord is not OC-enabled, so no OCNotification subtype will be generated for the entity, neither a global notification element.
tipClass: objectDeletionNotification
Related to issue #15 in Mantis objectDeletionNotification
Mapping Rule
For an entity artifact in a TIP model, tipClass:objectDeletionNotification takes value from the set {YES,NO,NA}. If the value is NO or NA, nothing will be generated. If the value is YES (in this case, we can say that this entity is ODel-enabled), an subtype of TIP Common ODelNotification (refer to ) and a global element with a payload of this subtype will be generated.
The name of the subtype is <EntityName>ODelN, where the <EntityName> is short name of the entity, for example, for an entity named org.tmforum.tip.service.problem.ServiceProblem, <EntityName> is ServiceProblem, so the subtype name is ServiceProblemODelN. The subtype is in the same namespace with the entity, and its structure is:
<xsd:complexType name="<EntityName>ODelN">
<xsd:complexContent>
<xsd:extension base="<prefix of the namespace of TIP Common notifications>:ODelNotification">
<xsd:sequence>
<xsd:element name="object" type="tns:<EntityName>" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
The name of the global element is <EntityName>ODelN, where the <EntityName> is the short name of the entity with first character changed to lower case. For example, for an entity named org.tmforum.tip.service.problem.ServiceProblem, <EntityName> is serviceProblem, so the global element name is serviceProblemODelN. The element is in the same namespace with the entity and notification subtype, and its structure is:
<xsd:element name="<EntityName>ODelN" type="tns:<EntityName>ODelN">
<xsd:annotation>
<xsd:documentation>
Event that is sent if an <EntityName> instance has been deleted.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
Example (tipClass:objectDeletionNotification=YES)
In TIP SPM model, if the entity org.tmforum.tip.service.problem.ServiceProblem is ODel-enabled, a Object Deletion notification type and a global element will be generated:
<xsd:complexType name="ServiceProblemODelN">
<xsd:complexContent>
<xsd:extension base="notifications:ODelNotification">
<xsd:sequence>
<xsd:element name="object" type="tns:ServiceProblem" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="serviceProblemODelN" type="tns:ServiceProblemODelN">
<xsd:annotation>
<xsd:documentation>
Event that is sent if an ServiceProblem instance has been deleted.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
Example (tipClass:objectDeletionNotification=NO or NA)
In TIP SPM model, the entity org.tmforum.tip.cbe.problem.TrackingRecord is not ODel-enabled, so no ODelNotification subtype will be generated for the entity.
tipClass: objectDiscoveryNotification
Related to issue #16 in Mantis objectDiscoveryNotification
Mapping Rule
For an entity artifact in a TIP model, tipClass:objectDiscoveryNotification takes value from the set {YES,NO,NA}. If the value is NO or NA, nothing will be generated. If the value is YES (in this case, we can say that this entity is ODisc-enabled), an subtype of TIP Common ODisNotification (refer to ) and a global element with a payload of this subtype will be generated.
The name of the subtype is <EntityName>ODisN, where the <EntityName> is short name of the entity, for example, for an entity named org.tmforum.tip.service.problem.ServiceProblem, <EntityName> is ServiceProblem, so the subtype name is ServiceProblemODisN. The subtype is in the same namespace with the entity, and its structure is:
<xsd:complexType name="<EntityName>ODisN">
<xsd:complexContent>
<xsd:extension base="<prefix of the namespace of TIP Common notification>:ODisNotification">
<xsd:sequence>
<xsd:element name="object" type="tns:<EntityName>" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
The name of the global element is <EntityName>ODisN, where the <EntityName> is the short name of the entity with first character changed to lower case. For example, for an entity named org.tmforum.tip.service.problem.ServiceProblem, <EntityName> is serviceProblem, so the global element name is serviceProblemODisN. The element is in the same namespace with the entity and notification subtype, and its structure is:
<xsd:element name="<EntityName>ODisN" type="tns:<EntityName>ODisN">
<xsd:annotation>
<xsd:documentation>
Event that is sent if an <EntityName> instance has been discovered.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
Example (tipClass:objectDiscoveryNotification=YES)
In TIP SPM model, if the entity org.tmforum.tip.service.problem.ServiceProblem is ODisc-enabled, a Object Discovery notification type and a global element will be generated:
<xsd:complexType name="ServiceProblemODisN">
<xsd:complexContent>
<xsd:extension base="notifications:ODisNotification">
<xsd:sequence>
<xsd:element name="object" type="tns:ServiceProblem" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="serviceProblemODisN" type="tns:ServiceProblemODisN">
<xsd:annotation>
<xsd:documentation>
Event that is sent if an ServiceProblem instance has been discovered.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
Example (tipClass:objectDiscoveryNotification=NO or NA)
In TIP SPM model, the entity org.tmforum.tip.cbe.problem.TrackingRecord is not ODisc-enabled, so no ODisNotification subtype will be generated for the entity.
Entity: Extendability
Refer to wiki page TIP_Generator_Internal_Model for more information about EntityBase and EntityIdentifier.
Mapping Rule
EntiyBase (org.tmforum.tip.internal.entity.EntityBase) is defined in TIP Generator Internal Model. It is mapped to an XSD complex type named 'EntityBase' in namespace http://www.tmforum.org/xml/tip/internal/entity.
In any model projects, if an entity is not explicitly given an ancestor, then in XSD, we will map it to a direct subtype of EntityBase XSD complex type.
EntityIdentifier (org.tmforum.tip.internal.entity.EntityIdentifier) is also defined in TIP Generator Internal Model. It is mapped to an XSD complex type named "EntityIdentifier" in namespace http://www.tmforum.org/xml/tip/internal/entity.
In TIP Generator Internal Model, EntityBase has an identifer of EntityIdentifier type. In XSD type hierachy, because every entity XSD type (that is, the image of the entity under the mapping rule) is subtype of EntityBase XSD type, so every entity XSD type has an identifier from the later one.
We give structure of EntityBase XSD type and EntityIdentifier XSD type.
EntityIdentifier XSD type:
<xsd:complexType name="EntityIdentifier">
<xsd:sequence>
<xsd:element name="scheme" type="tns:EntityIdentifierScheme"></xsd:element>
<xsd:element name="value" type="primitives:ArrayOfAnyType" minOccurs="0"></xsd:element>
<xsd:element name="context" type="primitives:ArrayOfAnyType" minOccurs="0"></xsd:element>
<xsd:element name="encoding" type="xsd:string" minOccurs="0"></xsd:element>
</xsd:sequence>
</xsd:complexType>
where ArrayOfAnyType is a complex type defined in internal_primitives.xsd:
<xsd:complexType name="ArrayOfAnyType">
<xsd:sequence>
<xsd:element name="item" type="xsd:anyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
EntityBase XSD type is:
<xsd:complexType name="EntityBase" abstract="true">
<xsd:annotation>
<xsd:documentation>
This is the base definition used for all TIP entities.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="identifier" type="tns:EntityIdentifier">
<xsd:annotation>
<xsd:documentation>
The entity instance identifier EID .
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="extensionInfo" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
<p>A generic list of any type of elements. Used for vendor Extensions or loose element
encapsulation from other namespaces.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Example (direct subtype of EntityBase)
In SPM model, the entity org.tmforum.tip.cbe.problem.Problem extends nothing, so it will be mapped to a direct subtype of XSD EntityBase. Now we give structure and content of Problem XSD type.
(note that many other attributes and association ends do not shown in this picture due to limited space)
<xsd:complexType name="Problem" abstract="true">
<xsd:annotation>
<xsd:documentation>
General description of a problem that can be shared between service and customer.
A Problem is an indication that an entity is no longer functioning according to the agreement with its client s .
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<xsd:element name="originatingSytem" type="xsd:string" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
Indicates where the problem was generated.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!--other many elements mapped from attributes and association ends-->
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Entity: Abstract
Related to issue #49 in Mantis Abstract Entity
Mapping rule
'isAbstract=true' is mapped to 'abstract=true' in XSD
'isAbstract=false' is ignored, that is, mapped to nothing.
Example (isAbstract=true)
In SPM model, the entity org.tmforum.tip.cbe.problem.Problem has 'isAbstract=true', it is mapped to an XSD type with 'abstract=true':
<xsd:complexType name="Problem" abstract="true" >......</xsd:complexType>
Example (isAbstract=false)
In SPM model, the entity org.tmforum.tip.service.problem.ServiceProblem has 'isAbstract=false', it is mapped to a normal XSD type:
<xsd:complexType name="ServiceProblem">......</xsd:complexType>
Entity: Inheritance
Related to issue #50 in Mantis Entity Inheritance
Mapping Rule
refer to TIP_Soap_Generator_Mapping_Rules
In a TIP model project,
- if the entity has no given ancestor (e.g. Problem in SPM model), we let its XSD type extend EntityBase XSD type.
- If the entity has an explicit ancestor (e.g. ServiceProblem extends Problem in SPM), we let XSD type of this entity extend XSD type of the ancesor. This needs to work even if the ancestor is in a dependency.
Note that in TIP model, it is no 'multiple inheritance' is allowed.
Example (entity has no ancestor given)
In SPM model, the entity org.tmforum.tip.cbe.problem.Problem has no given ancesotr, so it will be mapped to a direct subtype of XSD EntityBase. refer to example in TIP_Soap_Generator_Mapping_Rules
Example (entity has ancestor)
In SPM model, the entity org.tmforum.tip.cbe.problem.ServiceProblem extends Problem.
We can find ServiceProblem XSD in the file service_problem.xsd. In this XSD file, following XSD files are imported to resolve references:
<xsd:import namespace="http://www.tmforum.org/xml/tip/resource/trouble" schemaLocation="resource_trouble.xsd"/> <xsd:import namespace="http://www.tmforum.org/xml/tip/cbe/problem" schemaLocation="cbe_problem.xsd"/> <xsd:import namespace="http://www.tmforum.org/xml/tip/internal/entity" schemaLocation="internal_entity.xsd"/>
Now we give its content.
<xsd:complexType name="ServiceProblem">
<xsd:annotation>
<xsd:documentation>
A Service Problem is an indication that a service is no longer functioning according to the agreement with its client s .
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="problem:Problem">
<xsd:sequence>
<xsd:element name="underlyingAlarms" type="entity:ArrayOfEntityIdentifier" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
a set of alarm ids identifying the larms that are underlying to this problem. Note: a resource RC alarm would be an
underlying alarm also sometimes refer as a symptom for a service problem.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Entity: parent is in external reference
Related to issue #70 in Mantis Entity: parent is in external reference
It is N/A in meta-model and does not used in existing model projects (common, internal, test1, test2, and SPM), but can be supported in the generator.
Mapping Rule
Same with the case where parent is in the same model.
Refer to section “Entity: inheritance" (#50).
The generator calculates and generates the referenced XSD files on fly.
Example (parent is in external reference)
In Test1 model, for test, we let entity org.tmforum.tip.service.test2.ServiceTest to extend external entity org.tmforum.tip.service.service.Service, then in generated XSD, we can see (note that some attributes of ServiceTest is omitted from the picture due to limited space)
<xsd:complexType name="ServiceTest">
<xsd:annotation>
<xsd:documentation>
Test object used in test model.Use to test all possible datatypes.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="service:Service">
<xsd:sequence>
<xsd:element name="a_any" type="xsd:anyType">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element>other elements omitted</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Entity: Identifier
Related to issue #75 in Mantis Entity: Identifier
Mapping Rule
EntiyBase and EntityIdentifier are defined in TIP Generator Internal Model. EntityBase has an identifier of type EntityIdentifier. EntityBase and EntityIdentifier are mapped to XSD types as described in section TIP_Soap_Generator_Mapping_Rules
In XSD, every entity XSD type is derived from EntityBase XSD type directly or indirectly, so it inherits that identifier.
Example
Refer to section TIP_Soap_Generator_Mapping_Rules
Attribute: isInvariant
Related to issue #9 in Mantis Attribute: isInvariant
tipAtribute: isInvariant
For an attribute of an entity, tipAttribute:isInvariant can be true or false. There is no corresponding concept in XSD for it, so we put it to XSD documentation of the attribute.
Attribute: NotificationDefinition
Related to issue #10 in Mantis Attribute: NotificationDefinition
Mapping Rule
The value set of tipAttribute:notificationDefinition is {YES,NO,NA}. For an concrete entity in a TIP model, if at least one of its attributes or navigable association ends (local or inherited) has tipAttribute:notificationNotification=YES, a specific notification inheriting the TIP Common AVCNotification will be generated. In this case, we can say that this entity is AVC-enabled. This notification will contain all the AVC-enabled attributes. A global element with a payload of this notification type will be generated.
The name of the subtype is <EntityName>AVCN, where the <EntityName> is short name of the entity, for example, for an entity named org.tmforum.tip.service.problem.ServiceProblem, <EntityName> is ServiceProblem, so the subtype name is ServiceProblemAVCN. The subtype is in the same namespace with the entity, and its structure is:
<xsd:complexType name="<EntityName>AVCN">
<xsd:complexContent>
<xsd:extension base="<prefix of namespace of TIP Common notifications>:AVCNotification">
<xsd:sequence>
<xsd:element name="<name of a AVC-enabled attribute or end>" type="<type of the AVC-enabled attribute pr end>" minOccurs="0"/>
<xsd:element name="<name of a AVC-enabled attribute or end>" type="<type of the AVC-enabled attribute or end>" minOccurs="0"/>
<!-- more... -->
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
The name of the global element is <EntityName>AVCN, where the <EntityName> is the short name of the entity with first character changed to lower case. For example, for an entity named org.tmforum.tip.service.problem.ServiceProblem, <EntityName> is serviceProblem, so the global element name is serviceProblemAVCN. The element is in the same namespace with the entity and notification subtype, and its structure is:
<xsd:element name="<EntityName>AVCN" type="tns:<EntityName>AVCN">
<xsd:annotation>
<xsd:documentation>
Event that is sent if at least one of AVC-enabled attributes of a <EntityName> instance has been changed.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
Example
In TIP SPM model, the entity org.tmforum.tip.service.problem.ServiceProblem is AVC-enabled because in its association org.tmforum.tip.service.problem.ServiceProblemHasUnderlyingAlarms, the navigable end underlyingAlarms is AVC-enabled.
The entity is mapped to a XSD complex type named ServiceProblem in the namespace http://www.tmforum.org/xml/tip/service/problem. In the same namespace, a AVC notification type and a global element are generated:
<xsd:complexType name="ServiceProblemAVCN">
<xsd:complexContent>
<xsd:extension base="notifications:AVCNotification">
<xsd:sequence>
<xsd:element name="underlyingAlarms" type="entity:ArrayOfEntityIdentifier" minOccurs="0"></xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="serviceProblemAVCN" type="tns:ServiceProblemAVCN">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="event" type="tns:ServiceProblemAVCN"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Example (Entity not AVC-enabled)
In TIP SPM model, the entity org.tmforum.tip.cbe.problem.TrackingRecord is not AVC-enabled, so no AVCNotification subtype will be generated for the entity, neither a global AVC notification element.
Attribute: passedById
Related to issue #11 in Mantis Attribute: passedById
tipAttribute:passedById
This covers the use of the passedById on an attribute. It indicates a reference to an external class. By default, this case can only occur if the attribute is of type entity. This seems possible in RSM even if in most of the cases, this should be an association.
Mapping Rule
refer to TIP_Soap_Generator_Mapping_Rules
Example
In Test1 model, we have an entity org.tmforum.tip.service.test2.ServiceTest which has an attribute named 'allDTs'.
if allDTs has 'tipAttribute:passedById=true' and mulitplicity 0..1 , we have
<xsd:complexType name="ServiceTest">
<xsd:annotation>
<xsd:documentation>
Test object used in test model. Use to test all possible datatypes.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<!--other elements omitted-->
<xsd:element name="allDTs" type="entity:EntityIdentifier" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Note: if this attribute has 'tipAttribute:passedById=false', and has multiplicity 0..1, we have
<xsd:complexType name="ServiceTest">
<xsd:annotation>
<xsd:documentation>
Test object used in test model.
Use to test all possible datatypes.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<!--other elements omitted-->
<xsd:element name="allDTs" type="tns:TestAllDatatypes" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
if allDTs has 'tipAttribute:passedById=true' and mulitplicity 1, we have
<xsd:complexType name="ServiceTest">
<xsd:annotation>
<xsd:documentation>
Test object used in test model.
Use to test all possible datatypes.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<!--other elements omitted-->
<xsd:element name="allDTs" type="entity:EntityIdentifier">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Note: if this attribute has 'tipAttribute:passedById=false', and has multiplicity 1, we have
<xsd:complexType name="ServiceTest">
<xsd:annotation>
<xsd:documentation>
Test object used in test model.
Use to test all possible datatypes.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<!--other elements omitted-->
<xsd:element name="allDTs" type="tns:TestAllDatatypes">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
if allDTs has 'tipAttribute:passedById=true' and mulitplicity 0.., 1.., or * , we have
<xsd:complexType name="ServiceTest">
<xsd:annotation>
<xsd:documentation>
Test object used in test model.
Use to test all possible datatypes.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<!--other elements omitted-->
<xsd:element name="allDTs" type="tns:ArrayOfEntityIdentifier" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Note: if this attribute has 'tipAttribute:passedById=false', and has multiplicity 0.., 1.., or *, we have
<xsd:complexType name="ServiceTest">
<xsd:annotation>
<xsd:documentation>
Test object used in test model.
Use to test all possible datatypes.
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<!--other elements omitted-->
<xsd:element name="allDTs" type="tns:ArrayOfTestAllDatatypes" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Attribute: multiplicity
Related to issue #44 in Mantis Attribute: multiplicity
Mapping Rule
refer to mapping rule TIP_Soap_Generator_Mapping_Rules
Example (multiplicity=0..1)
originatingSystem has multiplicity 0..1, '0..1' in model is mapped to 'minOccurs=0 maxOccurs=1' in XSD.
<xsd:complexType name="Problem" abstract="true">
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<!--many elements correspond to attrubutes or association ends-->
<xsd:element name="originatingSytem" type="xsd:string" minOccurs="0"></xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Example (multiplicity=1)
impactImportanceFactor has multiplicity 1, it is mapped to 'minOccurs=1 maxOccurs=1' in XSD.
<xsd:complexType name="Problem" abstract="true">
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<!--many elements correspond to attrubutes or association ends-->
<xsd:element name="impactImportanceFactor" type="xsd:int"></xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Example (multiplicity=*)
Comments has multiplicity *, it's a list of org.tmforum.tip.cbe.problem.Comment
The attribute 'comments' is mapped to an element of type 'ArrayOfComment', with multiplicity 'minOccurs=0 maxOccurs=1' in XSD.
Example (mulitplicity=1..* and passedById=true)
In Test1 model, org.tmforum.tip.cbe.test.TestProblem has an attribute named clearTrackingRecords with mulitplicity ‘1..*’. This attribute is ‘passedById’, so it is mapped to an element of TestProblem XSD, the element has type “ArrayOfEntityIdentifier", with multiplicity “‘minOccurs=0 maxOccurs=1’".
If this attribute was not 'passedById', it had to be mapped to an element which has type 'ArrayOfTrackingRecord', with multiplicity 'minOccurs=0 maxOccurs=1'.
Attribute: readonly
Related to issue #45 in Mantis Attribute: readonly
These is no corresponding XSD concept.
We put it to XSD documentation of the attribute.
Attribute: default value
Related to issue #46 in Mantis Attribute: default value
show default value in XSD 'default' attribute.
Example
In TIP SPM model, the entity org.tmforum.tip.cbe.problem.Problem has an attribute named ackStatus which has default value 'UNACKNOLEDGED'. then in XSD:
<xsd:complexType name="Problem" abstract="true">
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<xsd:element name="ackStatus" type="tns:AckStatus" default="2">
<xsd:annotation>
<xsd:documentation>
Acknowledgement status. This attribute is not invariant.
<p>This attribute is mandatory. </p> <p>This attribute is not ordered. </p> <p>This attribute is unique. </p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<!-- other elements omited here -->
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Attribute: type is in external reference
Related to issue #69 in Mantis Attribute: type is in external reference
This covers the use case of an Attribute, whose type is not in the local project but part of an external reference, i.e. a module.
Mapping Rule
When map entity attribute to element of entity XSD, the generated element refers to external XSD type. The generator calculates and generates the referenced XSD files on fly.
Example (type is in external reference)
In Test1 model, the entity org.tmforum.tip.cbe.test.Test has an attribute named 'attribute0' which refer to external datatype org.tmforum.tip.cbe.tt.Datatype1.
<xsd:complexType name="Test">
<xsd:annotation>
<xsd:documentation>
Test class for use in the test model
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<xsd:element name="attribute0" type="tt:ExtDatatype1">
<xsd:annotation>
<xsd:documentation>
attributes with external reference
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="testProblem" type="entity:ArrayOfEntityIdentifier" minOccurs="0">
<xsd:annotation>
<xsd:documentation>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="_testProblem" type="tns:TestProblem">
<xsd:annotation>
<xsd:documentation>
WARNING : End details copied form parent
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Association End Support
refer to TIP_Soap_Generator_Mapping_Rules