TIP Main Page | TIP Framework | TIP Soap Generator | TIP Soap Generator Mapping Rules - Part III

Mapping Rules for Datatypes

Complex datatype support

Related to issue #43 in Mantis Complex datatype support

Mapping Rule

Map a Data Type artifact to two XSD complex types: single one and array.

Example

In SPM model, org.tmforum.tip.cbe.problem.ImpactPatterns is a Datatype artifact. This artifact has been mapped to two XSD complex types:

• ImpactPatterns, and

• ArrayOfImpactPatterns

Two XSD complex types: ImpactPatterns and ArrayOfImpactPatterns:

We give their XSD contents:


    <xsd:complexType name="ImpactPatterns">
	<xsd:annotation>
	    <xsd:documentation>
                Define the patterns of impact  optional . It can be other service characteristics.
                It is used when defining impact through another pattern than the pre-defined attributes above.
                This is an empty class that will be augmented/extended by specific projects
            </xsd:documentation>
	</xsd:annotation>
	<xsd:sequence>
	    <xsd:element name="description" type="xsd:string">
		<xsd:annotation>
		    <xsd:documentation>
                       Basic description of the ipact pattern.
                    </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>


    <xsd:complexType name="ArrayOfImpactPatterns">
	<xsd:sequence>
	    <xsd:element name="item" type="tns:ImpactPatterns" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
	</xsd:sequence>
    </xsd:complexType>

Datatype: abstract

Relateo issue #48 in Mantis Datatype: abstract

Mapping Rule

• If isAbstract=true, will map to abstract XSD type

• If isAbstract=false, will map to normal XSD type

Example

In Test1 model, org.tmforum.tip.cbe.test.AbstractDatatype has isAbstract=ture. It is mapped to XSD as:


    <xsd:complexType name="AbstractDatatype" abstract="true">
	<xsd:annotation>
	    <xsd:documentation>
                 Example of abstract datatype
	    </xsd:documentation>
	</xsd:annotation>
	<xsd:sequence>
	    <xsd:element name="attribute0" type="xsd:string">
		<xsd:annotation>
		    <xsd:documentation>
                    </xsd:documentation>
		</xsd:annotation>
	    </xsd:element>
	    <xsd:element name="attribute1" type="xsd:string">
		<xsd:annotation>
		    <xsd:documentation>
                    </xsd:documentation>
		</xsd:annotation>
	    </xsd:element>
	    <xsd:element name="attribute2" type="xsd:string">
		<xsd:annotation>
		    <xsd:documentation>
                    </xsd:documentation>
		</xsd:annotation>
	    </xsd:element>
	</xsd:sequence>
    </xsd:complexType>

Datatype: Extendability

Related to issue #17 in Mantis Datatype: isExtendable

Mapping Rule

refer to TIP_Soap_Generator_Mapping_Rules. If a datatype has 'tipDatatype:isExtendable=true', the generator will inject an additional element to corresponding XSD type of the datatype.

Example

refer to previous example: org.tmforum.tip.cbe.problem.ImpactPatterns

Datatype: inheritance

Mapping Rule

refer to TIP_Soap_Generator_Mapping_Rules. Map inheritance of datatype artifacts to extension of datatype XSD types.

Example

In Test1 model, org.tmforum.tip.cbe.test.TestDatatype extends org.tmforum.tip.cbe.test.AbstractDatatype. This relationship is mapped to XSD language:


    <xsd:complexType name="TestDatatype">
	<xsd:annotation>
	    <xsd:documentation>
            </xsd:documentation>
	</xsd:annotation>
	<xsd:complexContent>
	    <xsd:extension base="tns:AbstractDatatype">
		<xsd:sequence>
		    <xsd:element name="attribute3" type="xsd:string">
			<xsd:annotation>
			    <xsd:documentation>

                            </xsd:documentation>
			</xsd:annotation>
       		    </xsd:element>
		</xsd:sequence>
	    </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

Mapping Rules for Exceptions

Exception Base support

Related to issue #346 in Mantis Exception Base Support

Mapping Rule

ExceptionBase (org.tmforum.tip.common.exceptions.EntityBase) is defined in TIP Common Model. It is mapped to an XSD complex type named 'ExceptionBase' in namespace http://www.tmforum.org/xml/tip/common/exceptions.

In any TIP model projects, exception artifacts will extend ExceptionBase directly or indirectly. In particular, if an exception artifact is not explicitly given an ancestor in a TIP model project, we will map it to a direct subtype of ExceptionBase XSD complex type.

We give structure of ExceptionBase XSD type.


    <xsd:complexType name="ExceptionBase" abstract="true">
	<xsd:annotation>
	    <xsd:documentation>
              This is the base definition of all TIP operation exceptions.
            </xsd:documentation>
	</xsd:annotation>
	<xsd:sequence>
	    <xsd:element name="reason" type="xsd:string">
		<xsd:annotation>
		    <xsd:documentation>
      Free string to define the reason the exception was raised. It should be a short text. Might reference the step in the use case where this exception occurs, if a detailed use case was made for this operation.
                    </xsd:documentation>
		</xsd:annotation>
	    </xsd:element>
	    <xsd:element name="details" type="xsd:string">
		<xsd:annotation>
		    <xsd:documentation>
                      The more specific details about the exception. Can also be a stack trace.
                    </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 ExceptionBase)

In Test1 model, the exception artifact org.tmforum.tip.cbe.test.TestFailure extends ExceptionBase.


    <xsd:complexType name="TestFailure">
	<xsd:annotation>
	    <xsd:documentation>
                 Simple private exception
            </xsd:documentation>
	</xsd:annotation>
        <xsd:complexContent>
	    <xsd:extension base="exceptions:ExceptionBase">
		<xsd:sequence/>
	    </xsd:extension>
	</xsd:complexContent>
    </xsd:complexType>

Exception: attribute support

Related to issue #68 in Mantis Exception: attribute support

Mapping Rule

All Exception artifacts are mapped to XSD complex types, and under this mapping, the attributes of artifacts are mapped to sub-elements of the XSD complex types.

For details, refer to TIP_Soap_Generator_Mapping_Rules

Example

In Test1 model, we have org.tmforum.tip.cbe.test.TestFailureWithData. Some of their attributes is of primitive type, some is of Datatype type, some is of Enumeration type, and some is of Entity type.


    <xsd:complexType name="TestFailureWithData">
	<xsd:annotation>
	    <xsd:documentation>
               Simple private exception with data
            </xsd:documentation>
	</xsd:annotation>
	<xsd:complexContent>
     	    <xsd:extension base="exceptions:ExceptionBase">
		<xsd:sequence>
		    <xsd:element name="excep0" type="xsd:string">
			<xsd:annotation>
			    <xsd:documentation>
      
                            </xsd:documentation>
			</xsd:annotation>
		    </xsd:element>
		    <xsd:element name="excep1" type="tns:ActivityStatus">
			<xsd:annotation>
			    <xsd:documentation>
      
                            </xsd:documentation>
			</xsd:annotation>
		    </xsd:element>
		    <xsd:element name="excep2" type="tns:ImpactPatterns">
			<xsd:annotation>
			    <xsd:documentation>
      
                            </xsd:documentation>
			</xsd:annotation>
		    </xsd:element>
		    <xsd:element name="excep3" type="tns:Test">
			<xsd:annotation>
			    <xsd:documentation>
      
                            </xsd:documentation>
			</xsd:annotation>
   		    </xsd:element>
		</xsd:sequence>
	    </xsd:extension>
	</xsd:complexContent>
    </xsd:complexType>

Example

In Test1 model, we have org.tmforum.tip.cbe.test.TestFailure which extends org.tmforum.tip.common.exceptions.ExceptionBase and with no more attribute added.

[File__TestFailure.JP


    <xsd:complexType name="TestFailure">
	<xsd:annotation>
	    <xsd:documentation>
                 Simple private exception
            </xsd:documentation>
	</xsd:annotation>
        <xsd:complexContent>
	    <xsd:extension base="exceptions:ExceptionBase">
		<xsd:sequence/>
	    </xsd:extension>
	</xsd:complexContent>
    </xsd:complexType>

Exception__Inheritance

Mapping Rule

refer to [TIP_Soap_Generator_Mapping_Rules. Map inheritance of exception artifacts to extension of exception XSD types.

Example

In Test1 model, the exception artifact org.tmforum.tip.cbe.test.TestFailureWithData extends org.tmforum.tip.cbe.test.TestFailure, refer to previous section for definition of TestFailureWithData XSD type.

Exception: Extendability

Mapping Rule

When map ExceptionBase artifact to XSD complex type, the generator will inject an additional sub-element called extensionInfo. please refer to mapping rule in section TIP_Soap_Generator_Mapping_Rules. For the structure of the sub-element, please refer to TIP_Soap_Generator_Mapping_Rules.

All other exception artifacts will be mapped to a (direct or indirect) subtype of ExceptionBase XSD type, so all exception XSD type inherit that extensionInfo sub-element. In particular, if an exception aritifact is not explicitly given an ancestor, then in XSD, we will map it to a direct subtype of ExceptionBase XSD type.

Example

for examples, please refer to sections:

TIP_Soap_Generator_Mapping_Rules

Mapping Rules for Notifications

Notification: abstract

Related to issue #64 in Mantis Notification: Abstract

Mapping Rule

Map to abstract XSD type.

Example

In Test1 model, org.tmforum.tip.service.test.AbstractTestEvent has 'isAbstract=true'


    <xsd:complexType name="AbstractTestEvent" abstract="true">
		<xsd:annotation>
			<xsd:documentation>
                           AbstractTestEvent
                        </xsd:documentation>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="notifications:NotificationBase">
				<xsd:sequence>
					<xsd:element name="notif0" type="xsd:string">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="notif1" type="xsd:date">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="notif2" type="test:AckStatus">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
    </xsd:complexType>

Notification: Notification Generic Inheritance Rule

Notifications extend from their explicitly declared extension point or from NotificationBase if there is
no extension specified.

All common notifications (AVCNotification, OCNotification, ODelNotification, ODiscNotification) are inheriting from CommonNotification.

Notification: Common Notification Base Support

All common notifications (AVCNotification, OCNotification, ODelNotification, ODiscNotification) are inheriting from CommonNotification in xsd.

For example AVCNotification:

  <xsd:complexType name="AVCNotification">
    <xsd:annotation>
      <xsd:documentation>
        <p>a generic Attribute Value Change event, ancestor of all specific Attribute Value Change
          events</p>
        <p>This notification is optional</p>
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="tns:CommonNotification">
        <xsd:sequence>
          <xsd:element name="extensionInfo" minOccurs="0">
            <xsd:annotation>
              <xsd:documentation> a generic list of any type of elements. Used for vendor extensions
                or loose element encapsulation from other namespaces. </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:extension>
    </xsd:complexContent>
  </xsd:complexType>

where CommonNotification :

 <xsd:complexType name="CommonNotification">
    <xsd:annotation>
      <xsd:documentation>
        <p>This is the root of the TIP Framework user modifiable Notification Hierarchy. All
          Notifications/Events defined by an interface designer using the TIP Framework should
          extend from CommonNotification</p>
        <p>This notification is optional</p>
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="notifications:CommonNotificationBase">
        <xsd:sequence> </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

and :

  <xsd:complexType name="CommonNotificationBase" abstract="true">
      <xsd:annotation>
         <xsd:documentation>
            <p>This is the base (abstract) definition used for all TIP common notifications. This
               type is injected by the TIP Generators into all events inheriting from
               CommonNotification.</p>
            <p>This notification is abstract</p>
            <p>This notification is optional</p>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:complexContent>
         <xsd:extension base="tns:NotificationBase">
            <xsd:sequence>
               <xsd:element name="objectType" type="xsd:string" minOccurs="1" maxOccurs="1">
                  <xsd:annotation>
                     <xsd:documentation>
                        <p>The type (class) of the object associated with the event. This attribute
                           is needed to allow simple notification filtering based on the obj</p>
                        <p>This element is generated from an attribute.</p>
                        <p>This attribute is mandatory</p>
                     </xsd:documentation>
                  </xsd:annotation>
               </xsd:element>
               <xsd:element name="objectId" type="entity:EntityIdentifier" minOccurs="1"
                  maxOccurs="1">
                  <xsd:annotation>
                     <xsd:documentation>
                        <p>Entity Identifier of the object associated with the event. This attribute
                           is needed to allow simple notification filtering based on the object
                           id.</p>
                        <p>This element is generated from an attribute.</p>
                        <p>This attribute is mandatory</p>
                     </xsd:documentation>
                  </xsd:annotation>
               </xsd:element>
            </xsd:sequence>
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>

Notification: Notification Base Support

Mapping Rule

NotificationBase (org.tmforum.tip.common.notifications.NotificationBase) is the base (abstract) definition used for all TIP notifications, and is defined in TIP Common Model. It is mapped to an XSD complex type named 'NotificationBase' in namespace http://www.tmforum.org/xml/tip/common/notifications.

Any TIP notification artifact will be mapped to a (direct or indirect) subtype of NotificationBase XSD type. In particular, if a notification artifact is not explicitly given an ancestor, then in XSD, we will map it to a direct subtype of the NotificationBase XSD type.

The structure of the NotificationBase XSD type is.


     <xsd:complexType name="NotificationBase" abstract="true">
      <xsd:annotation>
         <xsd:documentation>
            <p>This is the base (abstract) definition used for all TIP notifications.
This type is injected by the TIP Generators into code generated from Tigerstripe Event (i.e. notification) artifacts where the 'Extends' field has been left as an empty string.</p>
            <p>This notification  is  abstract</p>
            <p>This notification  is  optional</p>
         </xsd:documentation>
      </xsd:annotation>
      <xsd:sequence>
         <xsd:element name="sourceTime" type="xsd:time" minOccurs="1" maxOccurs="1">
            <xsd:annotation>
               <xsd:documentation>
                  <p>The time at which the event was reported by the source system (NE, EMS or OS).
It is the current time on the system where the event is generated.
If a system (like an EMS) is carrying forward an event generated on a NE, then the time of the source (NE in this case) should be kept.</p>
                  <p>This element is generated from an attribute.</p>
                  <p>This attribute  is  mandatory</p>
               </xsd:documentation>
            </xsd:annotation>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>

Example (direct subtype of NotificationBase)

In Test1 model, the notification artifact org.tmforum.tip.service.test.TestEvent extends NotificationBase.


    <xsd:complexType name="TestEvent">
	<xsd:annotation>
	    <xsd:documentation>
                TestEVent associated to the Service Problem Interface. Can be sent by the interface in addition to standard events
            </xsd:documentation>
	</xsd:annotation>
	<xsd:complexContent>
	    <xsd:extension base="notifications:NotificationBase">
		<xsd:sequence>
		    <xsd:element name="attribute0" type="xsd:string">
			<xsd:annotation>
			    <xsd:documentation>
      
                            </xsd:documentation>
			</xsd:annotation>
		    </xsd:element>
		    <xsd:element name="attribute1" type="xsd:boolean">
			<xsd:annotation>
			    <xsd:documentation>
      
                            </xsd:documentation>
		        </xsd:annotation>
		    </xsd:element>
		    <xsd:element name="attribute2" type="test:TestAssociatedWithTestProblem">
			<xsd:annotation>
			    <xsd:documentation>
                            </xsd:documentation>
			</xsd:annotation>
		    </xsd:element>
		    <xsd:element name="attribute3" type="test:TrackingRecord">
			<xsd:annotation>
			    <xsd:documentation>
      
                            </xsd:documentation>
			</xsd:annotation>
		    </xsd:element>
		    <xsd:element name="attribute4" type="test:ClearStatus">
			<xsd:annotation>
			    <xsd:documentation>
 
                            </xsd:documentation>
			</xsd:annotation>
		    </xsd:element>
		</xsd:sequence>
	    </xsd:extension>
	</xsd:complexContent>
    </xsd:complexType>

Notification: inheritance

Related to issue #65 in Mantis Notification: Inheritance

Mapping Rule

Map inheritance of notification artifacts to extension of XSD complex types.

If a notification artifact has no explicitly ancestor, it will be mapped to a direct subtype of NotificationBase XSD type.

Example (direct subtype of NotificationBase)

In Test1 model, the notification org.tmforum.tip.service.test.TestEvent which is a direct subtype of NotificationBase:

refer to section TIP_Soap_Generator_Mapping_Rules for examples.

Example (indirect subtype of NotificationBase)

In Test1 model, we org.tmforum.tip.service.test.TestEvent2 which is a direct subtype of org.tmforum.tip.service.test.AbstractTestEvent.

 

    <xsd:complexType name="TestEvent2">
		<xsd:annotation>
			<xsd:documentation>
                             Inherits from abstract event
                        </xsd:documentation>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="tns:AbstractTestEvent">
				<xsd:sequence>
					<xsd:element name="attribute0" type="entity:EntityIdentifier">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
          </xsd:complexType>

Notification: attribute support

Related to issue #66 in Mantis Notification: Attribute Support

Mapping Rule

Just as we did for entity attributes of entities and datatypes. (Map every attribute to XSD element)

Example

Refer to previous examples

Notification: Extendability

Mapping Rule

When map NotificationBase artifact to XSD complex type, an additional sub-element named extensionInfo is injected into. please refer to mapping rule in section TIP_Soap_Generator_Mapping_Rules

All other notification artifacts will be mapped to a (direct or indirect) subtype of Notification XSD type, so they will inherit that extensionInfo sub-element. In particular, if a notification aritifact is not explicitly given an ancestor, then in XSD, we will map it to a direct subtype of Notification XSD type.

Example

for examples, please refer to sections:

TIP_Soap_Generator_Mapping_Rules

Mapping Rules for Enumerations

Int based Enum support

Related to issue #41 in Mantis Int based Enum support

We will not use int based enumeration in TIP models.

string based Enum support

Related to issue #42 in Mantis String based Enum support

Mapping Rule

A string-based Enumeration artifact is mapped to an XSD simpleType which is restriction of XSD string type. The values of literals of the artifact are mapped to value of XSD enumeration.

Example

Test1 model has an enumeration artifact org.tmforum.tip.cbe.test.AckStatus, its literals are String.

The enumeration artifact is mapped to following XSD simpleType:

    <xsd:simpleType name="AckStatus">
	<xsd:annotation>
	    <xsd:documentation>
		<p>Defines the possible values for acknowledgement.</p>
		<p>It is used to indicate whether the associated object is handled or not by the client.</p>
            </xsd:documentation>
	</xsd:annotation>
	<xsd:restriction base="xsd:string">
	    <xsd:enumeration value="ACKNOWLEDGED">
		<xsd:annotation>
		    <xsd:documentation>
          
                    </xsd:documentation>
		</xsd:annotation>
	    </xsd:enumeration>
	    <xsd:enumeration value="UNACKNOWLEDGED">
		<xsd:annotation>
		    <xsd:documentation>
          
                    </xsd:documentation>
		</xsd:annotation>
	    </xsd:enumeration>
	</xsd:restriction>
    </xsd:simpleType>

Enum: abstract

Related to issue #47 in Mantis Enum: abstract

We will not use abstract enumeration in TIP model.

Enum: Extendability

tipDatatype is applicable to enumeration artifacts, but we will not talk about extendability for enums.

Mapping Rules for Primitives

Please refer to XML Schema Part 2: Datatypes Second Edition (W3C Recommendation 28 October 2004) for more information about XSD anyType.

Primitive type: any

Related to issue #28 in Mantis Primitive type:any

Mapping Rule

Map to anyType in XSD.

Example

Test1 model, the entity org.tmforum.tip.service.test2.ServiceTest has an attribute of type 'any'.

ServiceTest is mapped to following XSD type (note that some attributes 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="entity:EntityBase">
				<xsd:sequence>
					<xsd:element name="a_any" type="xsd:anyType">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_boolean" type="xsd:boolean">
						<xsd:annotation>
							<xsd:documentation>
                                                              dummy attribute 0
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_byte" type="xsd:byte">
						<xsd:annotation>
							<xsd:documentation>
                                                            dummy attribute 1
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_char" type="xsd:string">
						<xsd:annotation>
							<xsd:documentation>
                                                             dummy attribute 2
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_date" type="xsd:date">
						<xsd:annotation>
							<xsd:documentation>
                                                               dummy attribute 3
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_double" type="xsd:double">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_float" type="xsd:float">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_int" type="xsd:int">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_long" type="xsd:long">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_short" type="xsd:short">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_string" type="xsd:string">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<xsd:element name="a_time" type="xsd:time">
						<xsd:annotation>
							<xsd:documentation>
      
                                                        </xsd:documentation>
						</xsd:annotation>
					</xsd:element>
					<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>

This datatype is used by the import tool when hitting a datatype in the information model that it does not know how to translate. The use of this datatype avoids the corresponding attribute being suppressed hiding the error. The generators should issue an error if finding this datatype.

Mapping Rule

Map to anyURI in XSD, but issue an error message.

Example

Test1 model has an datatype org.tmforum.tip.service.test2.UnknownTest, it has an attribute of 'unknown' type, the generator map it to XSD 'anyURI' type, but issue following message:

ERROR org.eclipse.tigerstripe.generators.xml.helpers.XsdReferencesMgr [25-Sept-2009 15:23:13.796] - 
Artifact 'org.tmforum.tip.service.test2.UnknownTest' has an attribute of 'unknown' type, this type is not supported.

Primitive type: unsignedInteger

Related to issue #39 in Mantis Primitive type: unsignedInteger

Mapping Rule

Map to unsignedInt in XSD

Example

NA in Test models

Primitive type: byte

Related to issue #76 in Mantis Primitive type: byte

Mapping Rule

Map to byte in XSD

Example

Test1 model, org.tmforum.tip.service.test2.ServiceTest

Primitive type: objectName

Mapping Rule

Map objectName to EntityIdentifier in XSD

Primitive type: Array of Primitives

We should generate following types (in common or internal XSD) because they will be refered by attributes, association ends, or parameters:

ArrayOfAny

ArrayOfBoolean

ArrayOfChar

Only in JOSIF V1.1.

Primitive type: Filter

Mapping Rule

Operation using primitive filters as input arguments are mapped to operations using query filters which are XPATH expressions.

refer to *TIP_Soap_Generator_Mapping_Rules_-_Part_VII