Using XML Schema with TTCN-3 - ETSI



ETSI ES/MTS-201 873-9 V0.2.0 (2007-05)

ETSI Standard

Methods for Testing and Specification (MTS);

The Testing and Test Control Notation version 3;

Part 9: Using XML Schema with TTCN-3

Reference

DES/MTS-xxx

Keywords

MTS, Testing, TTCN, XML

ETSI

650 Route des Lucioles

F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C

Association à but non lucratif enregistrée à la

Sous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from:



The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at

If you find errors in the present document, send your comment to:

editor@etsi.fr

Copyright Notification

No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2005.

All rights reserved.

Contents

1 Scope 6

2 References 6

3 Abbreviations 7

4 Introduction 8

5 Mapping XML Schemas 9

5.1 Namespaces and document references 11

5.2 Identifier name conversion 13

5.3 Unsupported features 15

6 Built-in data types 16

6.1 Mapping of facets 16

6.1.1 length 17

6.1.2 minLength 17

6.1.3 maxLength 18

6.1.4 pattern 18

6.1.5 enumeration 19

6.1.6 whiteSpace 20

6.1.7 minInclusive 20

6.1.8 maxInclusive 20

6.1.9 minExclusive 21

6.1.10 maxExclusive 21

6.1.11 totalDigits 21

6.2 String types 22

6.2.1 string 22

6.2.2 normalizedString 22

6.2.3 token 22

6.2.4 Name 23

6.2.5 NMTOKEN 23

6.2.6 NCName 23

6.2.7 ID 23

6.2.8 IDREF 23

6.2.9 ENTITY 23

6.2.10 hexBinary 23

6.2.11 base64Binary 24

6.2.12 anyURI 24

6.2.13 language 25

6.2.14 NOTATION 25

6.3 Integer types 25

6.3.1 integer 25

6.3.2 positiveInteger 25

6.3.3 nonPositiveInteger 25

6.3.4 negativeInteger 25

6.3.5 nonNegativeInteger 25

6.3.6 long 26

6.3.7 unsignedLong 26

6.3.8 int 26

6.3.9 unsignedInt 26

6.3.10 short 26

6.3.11 unsignedShort 26

6.3.12 byte 26

6.3.13 unsignedByte 27

6.4 Float types 27

6.4.1 decimal 27

6.4.2 float 27

6.4.3 double 27

6.5 Time types 27

6.5.1 duration 27

6.5.2 dateTime 27

6.5.3 time 28

6.5.4 date 28

6.5.5 gYearMonth 28

6.5.6 gYear 28

6.5.7 gMonthDay 28

6.5.8 gDay 28

6.5.9 gMonth 28

6.6 Sequence types 29

6.6.1 NMTOKENS 29

6.6.2 IDREFS 29

6.6.3 ENTITIES 29

6.6.4 QName 29

6.7 Boolean type 30

6.8 anyType, anySimpleType types 30

7 Mapping XSD components 31

7.1 Attributes of XSD component declarations 31

7.1.1 id 32

7.1.2 ref 32

7.1.3 name 32

7.1.4 minOccurs and maxOccurs 32

7.1.5 default and fixed 33

7.1.6 form 34

7.1.7 type 34

7.1.8 mixed 34

7.1.9 abstract 34

7.1.10 block and final 34

7.2 schema component 34

7.3 element component 34

7.4 attribute components 35

7.5 simpleType components 36

7.5.1 Derivation by restriction 37

7.5.2 Derivation by list 37

7.5.3 Derivation by union 38

7.6 complexType components 39

7.6.1 complexType containing simpleContent 39

7.6.1.1 Extending simpleContent 39

7.6.1.2 Restricting simpleContent 40

7.6.2 complexType containing complexContent 40

7.6.2.1 Extending complexContent 40

7.6.2.2 Restricting complexContent 42

7.6.3 group components 42

7.6.4 all content 43

7.6.5 choice content 43

7.6.5.1 choice with nested element 43

7.6.5.2 choice with nested group 44

7.6.5.3 choice with nested choice 44

7.6.5.4 choice with nested sequence 45

7.6.5.5 choice with nested any 46

7.6.6 sequence content 46

7.6.6.1 sequence with nested element content 46

7.6.6.2 sequence with nested group content 47

7.6.6.3 sequence with nested choice content 47

7.6.6.4 sequence with nested sequence content 48

7.6.6.5 sequence with nested any content 49

7.6.7 attributeGroup components 49

7.7 any, anyAttribute 50

7.8 annotation 52

Annex A (normative): XSDAUX.ttcn3 XSD.ttcn3 53

Annex B (informative): Examples 57

Example 1 57

Example 2 60

Example 3 62

Example 4 64

Annex C (normative): List of reserved keywords 65

Annex D (normative): List and specification of encoding extension attributes 66

Annex E (informative): History 67

Intellectual Property Rights

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server ().

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

Scope

The present document defines the mapping rules for W3C Schema (as defined in [5, 6]) to TTCN-3 (as defined in ES 201 873-1 [1]) to enable testing of XML-based systems, interfaces and protocols. It is part 9 of a multi-part deliverable covering the Testing and Test Control Notation version 3, as identified below:

Part 1: "TTCN-3 Core Language";

Part 2: "TTCN-3 Tabular presentation Format (TFT)";

Part 3: "TTCN-3 Graphical presentation Format (GFT)";

Part 4: "TTCN-3 Operational Semantics";

Part 5: "TTCN-3 Runtime Interface (TRI)";

Part 6: "TTCN-3 Control Interface (TCI)";

Part 7: "Using ASN.1 with TTCN-3";

Part 8: "Using IDL with TTCN-3";

Part 9: "Using XML Schema with TTCN-3";

Part 10: "Using C/C++ with TTCN-3".

The specification of other mappings is outside the scope of the present document.

This ETSI Standard (ES) has been produced by ETSI Technical Committee Methods for Testing and Specification (MTS).

References

For the purpose of this ETSI Standard (ES) the following references apply:

[1] ETSI ES 201 873-1: 2005-06 2007-02, "Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language", Version 3.1.1 3.2.1

[2] W3C XML: 2004, Extensible Markup Language (XML) 1.1, W3C Recommendation, World Wide Web Consortium, .

[3] W3C XML Namespaces: 1999, Namespaces in XML, W3C Recommendation, World Wide Web Consortium, ,

[4] W3C XML Schema: 2004, XML Schema Part 0: Primer, W3C Recommendation, World Wide Web Consortium,

[5] W3C XML Schema: 2004, XML Schema Part 1: Structures, W3C Recommendation, World Wide Web Consortium,

[6] W3C XML Schema: 2004, XML Schema Part 2: Datatypes, W3C Recommendation, World Wide Web Consortium,

[7] IETF RFC 3986: 2005, "Uniform Resource Identifiers (URI): Generic Syntax"

[8] W3C SOAP version 1.2 Specification: 2003, W3C Recommendation, World Wide Web Consortium,

[9] I. Schieferdecker, B. Stepien: Automated Testing of XML/SOAP based Web Services, 13. Fachkonferenz der Gesellschaft für Informatik (GI) Fachgruppe "Kommunikation in verteilten Systemen" (KiVS), Leipzig, 26.-28. Feb. 2003.

[10] Dafina Maria Jeaca: XML Schema to TTCN-3 Mapping: Importing XMLSchema datatypes into TTCN-3, MSc Thesis, Politehnica University of Bucharest, Department of Computer Science, September 2004.

[11] W3C Information technology – ASN.1 encoding rules – mapping W3C XML schema definitions into ASN.1 ITU-T X.694

[12] W3C Information technology – ASN.1 encoding rules – XML encoding rules ITU-T X.693

[13] W3C Information technology – ASN.1 encoding rules – XML encoding rules Amendment 1 to ITU-T X.693

Abbreviations

For the purpose of the present document, the following abbreviations apply:

ASN.1 Abstract Syntax Notation One

TTCN-3 Testing and Test Control Notation

URI IETF Uniform Resource Identifier

W3C World Wide Web Consortium

XML W3C Extensible Markup Language

XSD W3C XML Schema

SOAP Simple Object Access Protocol

ς The whitespace character

Introduction

An increasing number of distributed applications use the XML format to exchange data for various purposes like data bases queries or updates or event telecommunications operations such as provisioning. All of these data exchanges follow very precise rules for data format description in the form of Document Type Description (DTD) [2, 3] or more recently the proposed XML Schemas [4, 5, 6]. There are even some XML based communication protocols like SOAP [8] that are based on XML Schemas. Like any other communication-based systems, components and protocols, XML based systems, components and protocols are candidates for testing using TTCN-3 [1]. Consequently, there is a need for establishing a mapping between XML data description techniques like DTD or Schemas to TTCN-3 standard data types.

The core language of TTCN-3 is defined in ES 201 873-1 [1] and provides a full text-based syntax, static semantics and operational semantics as well as a definition for the use of the language with ASN.1 in part 7 of the standard. The XML mapping provides a definition for the use of the core language with XML Schema structures and types, enabling integration of XML data with the language as shown in Figure 1.

[pic]

Figure 1: User's view of the core language and the various presentation formats

Mapping XML Schemas

There are two approaches to the integration of XML Schema and TTCN-3, which will be referred to as implicit and explicit mapping. The implicit mapping makes use of the import mechanism of TTCN-3, denoted by the keywords language and import. It facilitates the immediate use of data specified in other languages. Therefore, the definition of a specific data interface for each of these languages is required. The explicit mapping translates XML Schema definitions directly into appropriate TTCN-3 language artefacts.

In case of an implicit mapping an internal representation is produced from the XML Schema, which representation should retain all the structural and encoding information. This internal representation is not accessible by the user.

For explicit mapping, the information present in the XML Schema is mapped into accessible TTCN-3 code and - the XML structural information which does not have its correspondent in TTCN-3 code - into accesible encoding instructions.

The present document defines the mapping rules that have to be used by both of the approaches. XML DTDs need to be translated first into XML Schema before being mapped to TTCN-3. This may be done easily using available free or commercial tools.

The examples of this document are written in the assumption explicit mapping, although the difference is mainly in accessibility and visibility of generated TTCN-3 code and encoding instruction set.

The ITU recommendation X.694, published in 2004, describes mapping of XML Schema definitions into ASN.1 and E-XER encoding instructions (standardized in the ITU recommendation X.693 amendment 1, published a year earlier).

This standard, describing direct usage of XML from TTCN-3, should offer compatibility with the above solution, helping seamless migration from the ASN.1 based implementations to TTCN-3 based ones.

To migrate from an ITU-T Rec. X.694 based hybrid solution, where TTCN-3 message templates are written against ASN.1 code converted from XML Schema, to an entirely TTCN-3 based solution, the TTCN-3 type definitions plus the encoding extensions should replace the previously used ASN.1 plus E-XER encoding instructions without a significant impact on the rest of the TTCN-3 implementation (TTCN-3 templates especially) and on the produced XML documents.

For compatibility, the TTCN-3 code obtained from the XML Schema using this standard for an explicit mapping should be the same (while for an implicit mapping should have the same view) as the TTCN-3 code obtained from first converting the XML Schema using ITU-T Rec. X.694 into ASN.1 then converting the resulting ASN.1 into TTCN-3 code using ETSI 873-7. Moreover, the XML document produced by the TTCN-3 code with encoding extensions obtained from the XML Schema based on this standard (both for an explicit and implicit mapping) should be the same as the XML document produced by the ASN.1 with E-XER encoding based on ITU-T Rec. X.694 conversion of the same XML Schema.

This document is structured in two distinct parts:

Chapter ‎6 “

Built-in data types” defines the TTCN-3 mapping for all basic XSD data types like strings (see clause ‎6.2), integers (see clause ‎6.3), floats (see clause ‎6.4), etc. and facets (see clause ‎6.1) that allow for a simple modification of types by restriction of their properties (e.g. restricting the length of a string or the range of an integer).

Chapter ‎7 “

Mapping XSD components” covers the translation of more elaborate structures that are formed using the components shown in Table 1 and a set of XSD attributes (see clause ‎7.1) which allow for modification of constraints of the resulting types.

Table 1: Overview of XSD constructs

|Element |Defines tags that can appear in a conforming XML document. |

|attribute |Defines attributes for element tags in a conforming XML document. |

|simpleType |Defines the simplest types. They may be a built-in type, a list or choice of built-in types and |

| |they are not allowed to have attributes. |

|complexType |Defines types that are allowed to be composed, e.g. have attributes and an internal structure. |

|named model group |Defines a named group of elements. |

|attribute group |Defines a group of attributes that can be used as a whole in definitions of complexTypes. |

|identity constraint |Defines that a component has to exhibit certain properties in regard to uniqueness and |

| |referencing. |

1 Namespaces and document references

A single XSD Schema will be translated to a single TTCN-3 Module. A single XSD Schema will be translated to one ore more TTCN-3 modules, corresponding to schema components that have the same target namespace. Any XSD include / import statements are mapped to equivalent TTCN-3 import statements. An XSD Schema including another XSD Schema will be translated to two TTCN-3 modules , one importing from the other, both having the same target namespace. The module names generated by the translation are not standardized.

XML namespaces are supported only by means of incorporating any namespace qualifiers into the translated TTCN-3 identifier, as TTCN-3 does not offer a namespace concept. To do this, a translator has to first bring all XSD identifers to a unique qualified form (e.g. by evaluating the targetNamespace, elementFormDefault, and attributeFormDefault attributes of the XSD schema component and the xmlns and name attribute of every XSD component and combining them to a identifiers which are unique across all used schemas) and than translate these unique qualified names to TTCN-3 identifiers as described in clause ‎5.2.

As TTCN-3 does not offer a namespace concept, information about namespaces and prefixes (from targetNamespace, elementFormDefault, attributeFormDefault etc.) will be preserved not in the TTCN-3 code but in the encoding extensions (internal or external). To allow this, an extension permitting explicit specification of the namespaces and prefixes is introduced:

module MyModule

{

:

} with {

encode “XML”;

variant “namespace all, all in all as ‘’ prefix ‘ns0’”

}

All types declared in the module will inherit the namespace declaration of the module. This can be overridden by namespace declarations qualifying fields of declared structures:

Example:

module MyModule

{

:

type record MyRecordType

{

integer field1,

charstring field2

}

with {

variant (field1) “namespace as ‘’ prefix ‘ns1’”;

}

:

} with {

encode “XML”;

variant “namespace all, all in all as ‘’ prefix ‘ns0’”

}

template MyRecordType MyTemplate :=

{

field1 := 3,

field2 := “four”

}

will be encoded as:

< ns1:field1 xmlns:ns1=>3

< ns0:field2>four

If a module has no namespace declaration, all types and fields of types declared within the module are assumed to have no namespace ,except when a qualifying statement refers a declared type or field directly.

The importation structure of the TTCN-3 modules will retain the importation structure of the imported XML schemas. TTCN-3 ‘import’ statements will import types declared in other modules, and referrenced in the current module.

The control namespace ( the namespace of the type identification attributes and of the nil identification attribute) will be specified globally , with an encoding extension attached to the TTCN-3 module:

module MyModule

{

:

} with {

encode “XML”;

variant “controlNamespace ‘’ prefix ‘xsi’”

}

Qualifying declarations of the namespace prefixes can be used against templates, allowing re-declaration of namespace prefixes inherited from the referred types:

template MyRecordType MyTemplate2 :=

{

field1 := 3,

field2 := “four”

} with {

encode “XML”;

variant (field1) “namespace prefix ‘newns1’”;

variant (field2) “namespace prefix ‘newns0’”

}

will be encoded as:

3

four

For reception templates , wildcards (*,?) are allowed to be used in the prefix declaration.

For sake of clarity , wherever irrelevant, namespaces have been omitted from all most of the examples in this document.

2 Identifier name conversion

Translation of identifiers (e.g. type or field names) has a critical impact on the usability of conversion results: primarily, it must guarantee TTCN-3 consistency, but , in order to support migration of conversion results from code generated with tools based on ITU-T Rec. X.694, it must also generate identifiers compatible with that standard. It must also support portability of conversion results (the TTCN-3 code and the encoding instruction set) between TTCN-3 tools of different manufacturers, which is only possible if identifier conversion is standardised.

During the translation from XSD to TTCN-3 care has to be exercised when translating identifiers (e.g. type or field names). For different reasons a valid XSD identifier may not be valid in TTCN-3. For example it would be fine to specify both an attribute and an element of the same name in XSD. When mapped in a naïve fashion this would result in two different types with the same name in TTCN-3. A translator must therefore apply a name conversion scheme that guarantees unique identifier names in TTCN-3. As the name conversion may depend upon a concrete implementation of the TTCN-3 tool chain (e.g. not all compilers may be able to handle identifiers with prefixed underscores) the name conversion itself is not standardised.

A name conversion algorithm has to guarantee that the translated identifier name…

a) is unique within the scope it is to be used

b) contains only valid characters

c) is not a TTCN-3 keyword

d) is not a reserved word (“base” or “content”)

A translation that satisfies all the above criteria can be obtained with the following algorithm:

1. First , the transformations described in ch.10 (Name conversion) of recommendation ITU-T Rec. X.694 (Mapping W3C XML Schema definitions into ASN.1) have to be applied; this will result in identifiers consistent with the ASN.1 standards

2. Second, the transformations described in ch. 8.2 (Identifiers) of the ETSI standard ES 201 873-7 (Using ASN.1 with TTCN-3) have to be applied; this will result in identifiers both consistent with the TTCN-3 standard and compatible with conversion results of tools based on ITU-T Rec. X.694

A side effect of this algorithm is the possible distortion of identifiers (e.g. capitalization of type names when converting to ASN.1). Appropriate encoding instructions will have to control name conversion in the encoder/decoder.

Example(informative):

Will be translated as:

type record E0

{

charstring name,

integer index

}

With no encoding instructions, this will wrongly be encoded as:

name

3

Using the “name…as…” encoding instruction, names will be restored at both encoding and decoding:

type record E0

{

charstring name,

integer index

}

with {

variant “element”;

variant “name ‘E0’ as uncapitalized”;

}

template E0 MyE0Template :=

{

name := “name”,

index := 3

}

results in the following encoding:

name

3

Global encodings can be specified with encoding instructions attached to the module:

module MyModule

{

:

} with {

encode “XML”;

variant “name all as uncapitalized”

}

All identifiers within the examples of this document use the following algorithm for translation:

1. If the given type refers to a field:

Then go to rule 3

2. If the type is not named, has no id or does not references a type with a name:

Then use the name “ANONYM” and a sequential number (e.g. ANONYM1)

Else use the type’s name, id or referenced type’s name

NOTE: The sequential number needs to be unique per module as anonymous types are not to be used outside of a module.

3. If the name is a TTCN-3 keyword or a reserved word:

Then convert the name to uppercase letters

4. If the type is not an element:

Then postfix name with two underscores and and the type (e.g. foo__attribute)

5. If the type is defined in a namespace:

Then prefix the name with the namespace’s name and an underscore (e.g. ns_foo)

3 Unsupported features

XSD and TTCN-3 are very distinct languages. Therefore some features of XSD have no equivivalent equivalent in TTCN-3 or make no sense when translated to the TTCN-3 language. Whenever possible, these features are translated into encoding instructions completing the TTCN-3 code. The following list contains a compilation of these unsupported features.

a) Numeric types are not allowed to be restricted by patterns.

b) List types are not allowed to be restricted by enumerations or patterns.

c) Specifying the number of fractional digits for float types is not supported.

d) Mixed content is not supported.

e) Translation of the form attribute is not supported.

f) Translation of the abstract attribute is not supported.

g) Translation of the block attribute is not supported.

h) Translation of the final attribute is not supported.

i) All time types (see clause ‎6.5) restrict year to 4 digits.

Built-in data types

Built-in datatypes may be primitive or derived types. The latter are gained from primitive types by means of a restriction mechanism called facets. For the mapping of primitive types, a specific TTCN-3 module XSDAUX XSD is provided which defines the relation of XSD primitive types to TTCN-3 types. The capitalized type names used in Annex A of ITU-T Rec. X.694 have been retained for compatibility. All translated structures are the result of two subsequent transformations applied to the XSD Schema: first , transformations descibed in ITU-T Rec.X.694 , then transformations described in ETSI standard ES 201 873-7. In addition, specific extensions are used that allow codecs to keep track of the original XSD nature of a given TTCN-3 type.

Whenever a new simpleType is defined, with the base type a built-in one, it will be mapped directly from types defined in XSDAUX XSD:

Example:

Becomes

type XSDAUX.integer_ e1__simpleType;

type XSD.Integer E1

with {

variant “name ‘E1’ as uncapitalized ”;

};

In the following clauses both the principle mappings of facets and the translation of primitive types are given. The complete content of the XSDAUX XSD module is given in Annex A.

1 Mapping of facets

Table 2 summarises the facets for the built-in types that are supported in TTCN-3. Some of them may be supported in XML Schema but have no counterpart in TTCN-3 and therefore no mark in this table.

Table 2: Mapping support for facets of built-in types

| |

1 length

The facet length describes, how many units of length a value of the given simple type must have. For string and datatypes derived from string, length is measured in units of characters. For hexBinary and base64Binary and datatypes derived from them, length is measured in octets (8 bits) of binary data. For datatypes derived by list, length is measured in number of list items. A length-restricted XSD type is mapped to a corresponding length restricted type in TTCN-3, e.g.

Is translated to the following TTCN-3 type

type XSDAUX.string e2__simpleType length(10);

type XSD.String E2 length(10)

with {

variant “name ‘E2’ as uncapitalized”;

};

For built-in list types (see clause ‎6.6) the number of elements of the resulting set structure will be restricted. For example consider the following translation:

Mapped to TTCN-3:

type set length(10) of NMTOKEN e3__simpleType;

type NMTOKENS E3 length(10)

with {

variant “name ‘E3’ as uncapitalized”;

};

2 minLength

The facet minLength describes, how many units of length a value of the given simple type at least must have. It is mapped to a length restriction in TTCN-3 with a set lower boundary and an open upper boundary. Usage of the attribute fixed (see clause ‎7.1.5) has to be ignored. Consider this example:

Is translated to

type XSDAUX.string e4__simpleType length(3 .. infinity);

type XSD.String E4 length(3 .. infinity)

with {

variant “name ‘E4’ as uncapitalized”;

};

3 maxLength

The facet maxLength describes, how many units of length a value of the given simple type at most must have. It is mapped to a length restriction in TTCN-3 with a set upper boundary and a lower boundary of zero. Usage of the attribute fixed (see clause ‎7.1.5) has to be ignored. Consider this example:

Is mapped to

type XSDAUX.string e5__simpleType length(0 .. 5);

type XSD.String E5 length(0 .. 5)

with {

variant “name ‘E5’ as uncapitalized”;

};

4 pattern

The facet pattern describes a constraint in terms of a regular expression applied on a value space of a data type. For string based types this can be directly translated using the support in TTCN-3 for defining regular expression patterns on character sequences. It is not supported for numerical or boolean types. As the syntax for regular patterns differs between XSD and TTCN-3 a mapping of the pattern expression has to be applied. The symbols (, ), |, [, ], ^, - do not change and are translated directly. For the mapping of all other symbols please refer to Table 3 and Table 4.

[pic]

Unicode characters in XSD patterns are directly translated but the syntax changes from &#xgprc; in XSD to \q{g, p, r, c} in TTCN-3, where g, p, r, and c each represent a single hexadecimal character. Please note that in TTCN-3 only supports uppercase letters for hexadecimal characters and requires that all vallues values have to be are set.

Escaped characters in XSD are mapped to an escaped character in TTCN-3 or directly to the character (e.g. '.', and '+'). The double quote character must be mapped to an escaped double quote character. Character categories and blocks (like \p{Lu} or \p{IsBasicLatin}) are not supported. The correctness of the regular expression mappings themselves should be checked according to [1] Annex B.1.5. Consider the following example:

Will be mapped to the following TTCN-3 expresion:

type XSDAUX.string e6__simpleType (pattern "(ahi|eho|cre|dve)@(f|F)okus");

type XSD.String E6 (pattern "(ahi|eho|cre|dve)@(f|F)okus")

with {

variant “name ‘E6’ as uncapitalized”;

};

5 enumeration

The facet enumeration constraints the value space to a specified set of values for a type. It is not corresponding to the enumeration construct in TTCN-3, but will be mapped to a list of supplied values instead, e.g.

For reasons of compatibility with ITU-T Rec. X.694, it will be mapped to a TTCN-3 enumerated type along the principles described in ch 12.4 (The enumeration facet) of ITU-T Rec. X.694.

Example(informative):

Is mapped to:

type XSDAUX.string e7__simpleType ("rock", "paper", "scissors");

type enumerated E7 {rock,paper,scissors}

with {

variant “text all as capitalized”;

variant “name ‘E7’ as uncapitalized”;

}

While

Is mapped to:

type enumerated E7a {int0,int5,int10}

with {

variant “useNumber”;

variant “name ‘E7a’ as uncapitalized”;

};

This mapping is done similar for other types (e.g. numerical types).

6 whiteSpace

The whiteSpace facet has no corresponding feature in TTCN-3 but is preserved for the codec using a with-clause appropriate encoding instructions. For example:

This can be mapped into a charstring, sending information about the whiteSpace facet to the codec.

type XSDAUX.string e8__simpleType with {

type XSD.String E8

with {

variant "whiteSpace replace";

variant “name ‘E8’ as uncapitalized”;

};

For most built-in types the value of the whiteSpace facet is set to “collapse”, only the string type normalizedString (see clause ‎6.2.2), token (see clause ‎6.2.3), language (see clause ‎6.2.13), Name (see clause ‎6.2.4) and NCName (see clause ‎6.2.6) are allowed to specify this facet.

7 minInclusive

The minInclusive facet is only valid for numerical types. It specifies the lowest bound for a number, including the boundary. This is mapped to a range restriction in TTCN-3 with a given lower boundary and the upper boundary of the base type (or infinity if not set). Consider the following example:

Mapping of elements of type integer with minInclusive facet:

Is mapped to

type XSDAUX.integer_ e9__simpleType (-5 .. infinity);

type XSD.Integer E9 (-5 .. infinity)

with {

variant “name ‘E9’ as uncapitalized”;

};

8 maxInclusive

The maxInclusive facet is only valid for numerical types. It specifies the upmost bound for a number, including the boundary. This is mapped to a range restriction in TTCN-3 with a given upper boundary and the lower boundary of the base type (-infinity if not set). Consider the following example:

Mapping of elements of type integer with minInclusive facet:

Is mapped to

type XSDAUX.positiveInteger e10__simpleType (1 .. 100);

type XSD.PositiveInteger E10 (1 .. 100)

with {

variant “name ‘E10’ as uncapitalized”;

};

9 minExclusive

The mapping of minExclusive is very similar to minInclusive (see clause ‎6.1.7) only the given bound is not part of the range. A direct mapping of this is not possible in TTCN-3, as ranges are always including the given boundaries. To get around this a value delta needs to be defined which is the smallest possible number handled by the TTCN-3 compiler for a given type (e.g. 1 for integer types and something very small for a double). The boundary is then modified by adding the delta. Considering the mapping result of the example in clause ‎6.1.7 a translation with minExclusive facet would look like:

type XSDAUX.integer_ e11__simpleType (-4 .. infinity);

type XSD.Integer E11 (-4 .. infinity)

with {

variant “name ‘E11’ as uncapitalized”;

};

(The original boundary of -5 has been modified by the addition of a delta of 1).

10 maxExclusive

The mapping of maxExclusive is very similar to maxInclusive (see clause ‎6.1.8) only the given bound is not part of the range. A direct mapping of this is not possible in TTCN-3, as ranges are always including the given boundaries. To get around this a value delta needs to be defined which is the smallest possible number handled by the TTCN-3 compiler for a given type (e.g. 1 for integer types and something very small for a double). The boundary is then modified by subtracting the delta. Considering the mapping result of the example in clause ‎6.1.8 a translation with maxExclusive facet would look like:

type XSDAUX.positiveInteger e12__simpleType (1 .. 99);

type XSD.PositiveInteger E12 (1 .. 99)

with {

variant “name ‘E12’ as uncapitalized”;

};

(The original boundary of 100 has been modified by the subtraction of a delta of 1).

11 totalDigits

This facet defines the total number of digits a numeric value is allowed to have. It is mapped to TTCN-3 using ranges by converting the value of totalDigits to the proper boundaries of the numeric type in question, e.g.

Will be translated to

type XSDAUX.negativeInteger e13__simpleType (-999 .. -1);

type XSD.NegativeInteger E13 (-999 .. -1)

with {

variant “name ‘E13’ as uncapitalized”;

};

2 String types

XSD string types are generally converted to TTCN-3 as subtypes of universal charstring or octetstring. For an overview of the allowed facets please refer to Table 2 in clause ‎6.1. Following are details on the mapping of all string types of XSD.

To support mapping , the following type definitions are added to the built-in datatypes( utf8string is declared as a UTF-8 encoded subtype of universal charstring in Annex E2.2.0 of ETSI ES 201 873-1 [1]):

type utf8string XMLCompatibleString

(

char(0,0,0,9).. char(0,0,0,9),

char(0,0,0,10)..char(0,0,0,10),

char(0,0,0,12)..char(0,0,0,12),

char(0,0,0,32)..char(0,0,215,255),

char(0,0,224,0)..char(0,0,255,253),

char(0,1,0,0)..char(0,16,255,253)

)

type utf8string XMLStringWithNoWhitespace

(

char(0,0,0,33)..char(0,0,215,255),

char(0,0,224,0)..char(0,0,255,253),

char(0,1,0,0)..char(0,16,255,253)

)

type utf8string XMLStringWithNoCRLFHT

(

char(0,0,0,32)..char(0,0,215,255),

char(0,0,224,0)..char(0,0,255,253),

char(0,1,0,0)..char(0,16,255,253)

)

1 string

The string type is translated to TTCN-3 as a plain an XML compatible restriction of the universal charstring in XSDAUX XSD:

type charstring string XMLCompatibleString String with {

extension variant "XSD:string"

};

2 normalizedString

The normalizedString type is translated to TTCN-3 using the following pattern-restricted XML compatible restricted subtype of the universal charstring in XSDAUX XSD:

type charstring normalizedString XMLStringWithNoCRLFHT NormalizedString (pattern "[^\n\r\t]#(0,)") with {

extension variant "XSD:normalizedString"

};

3 token

The token type is translated to TTCN-3 using the following pattern-restricted charstring built-in datatype NormalizedString in XSDAUX XSD:

type charstring token NormalizedString Token (pattern "([^ς\t\r\n]#(1,)(ς[^ς\t\r\n]#(1,))#(0,))|") with {

extension variant "XSD:token"

};

4 Name

The NAME type is translated to TTCN-3 using the following pattern-restricted XML compatible restricted subtype of the universal charstring in XSDAUX XSD:

type charstring XMLStringWithNoWhitespace Name (pattern "[\w_:]#(1,)[\w\d_:-.]#(0,)") with {

extension variant "XSD:Name"

};

5 NMTOKEN

The NMTOKEN type is translated to TTCN-3 using the following pattern-restricted XML compatible restricted subtype of the universal charstring in XSDAUX XSD:

type charstring XMLStringWithNoWhitespace NMTOKEN (pattern "[\d\w_.:-]#(0,)") with {

extension variant "XSD:NMTOKEN"

};

6 NCName

The NCNAME type is translated to TTCN-3 using the following pattern-restricted charstring built-in datatype Name in XSDAUX XSD:

type charstring Name NCName (pattern "[a-zA-Z_]#1[\w_-.]#(0,)") with {

extension variant "XSD:NCName"

};

7 ID

The ID type is translated to TTCN-3 using the a pattern-restricted charstring built-in datatype NCName in XSDAUX XSD:

type charstring NCName ID (pattern "[\w_]#(1,)[\w\d_-.]#(0,)") with {

extension variant "XSD:ID"

};

8 IDREF

The IDREF type is translated to TTCN-3 using the a pattern-restricted charstring built-in datatype NCName in XSDAUX XSD:

type charstring NCName IDREF (pattern "[\w_]#(1,)[\w\d_-.]#(0,)") with {

extension variant "XSD:IDREF"

};

9 ENTITY

The ENTITY type is translated to TTCN-3 using the a pattern-restricted charstring built-in datatype NCName in XSDAUX XSD:

type charstring NCName ENTITY (pattern "[\w_]#(1,)[\w\d_-.]#(0,)") with {

extension variant "XSD:ENTITY"

};

10 hexBinary

The hexBinary type is translated to TTCN-3 using a plain octetstring in XSDAUX XSD:

type octetstring hexBinary HexBinary with {

extension variant "XSD:hexBinary"

};

A translation has to be aware of the fact that XSD hexBinary allows for the usage of lowercase letters (a, b, c, d, e, and f) for specification of values. These need to be converted to upper case for TTCN-3.

It is not legal to specify patterns for hexBinary types.

11 base64Binary

The XSD base64Binary type is translated to a pattern-restricted character string an octetstring in TTCN-3. As base64Binary is defined on 4-tuples of characters in XSD and charstring is defined on single characters in TTCN-3, a mapping has to take care of length adjustments (e.g. multiplying by four during translation). It is also necessary to strip possible trailing equal signs (“=”) from the XSD input before translating, which has implications on the length as well (a translated character string might be up to three characters shorter than calculated). Please refer to [6], clause 3.2.16 for more information on the specific padding mechanism. When encoding elements of this type, the XML codec will invoke automatically an appropriate base64 encoder; when decoding XML instance content, the base64 decoder will be called.

The base64Binary type mapped into TTCN-3 in XSDAUX XSD file is:

type charstring base64Binary (pattern "([0-9]|[a-z]|[A-Z]|\+|/)#(0,)") with {

extension "XSD:base64Binary"

};

type octetstring Base64Binary with {

variant "XSD:base64Binary";

};

Example:

will be translated as:

type XSD.Base64Binary E14

with {

variant “name ‘E14’ as uncapitalized”;

};

and a value:

template E14 MyBase64BinaryTemplate:= '546974616E52756C6573'O

will be encoded as:

VGl0YW5SdWxlcw==\r\n

Consider this example regarding length adjustmens with base64Binary types:

The length needs to be multiplied by four to accommodate the 4-tuples of characters. Together with the length adjustment for the potentially removed padding this translates to:

type XSDAUX.base64Binary e18__simpleType length(18 .. 20);

12 anyURI

The anyURI type is containing a URI is translated to TTCN-3 as a plain an XML compatible restricted subtype of the universal charstring in XSDAUX XSD:

type charstring anyURI XMLStringWithNoCRLFHT AnyURI with {

extension variant "XSD:anyURI"

};

NOTE: Finding a general pattern to restrict a charstring to all valid URIs may be possible (for the format see [7]), but the result would be complex, therefore decision was taken against specifying such a pattern.

13 language

The language type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD:

type charstring languageXSD Language (pattern "[a-zA-Z]#(1,8)(-[\w]#(1,8))#(0,)") with {

extension variant "XSD:language"

};

14 NOTATION

The XSD NOTATION type is not translated to TTCN-3.

3 Integer types

XSD integer types are generally converted to TTCN-3 as subtypes of integer-based types. For an overview of the allowed facets please refer to Table 2 in clause ‎6.1. Following are details on the mapping of all integer types of XSD.

1 integer

The integer type is not range-restricted in XSD and translated to TTCN-3 as a plain integer in XSDAUX XSD:

type integer integer_ Integer with {

extension variant "XSD:integer"

};

As “integer” is already a keyword, an underscore has to be appended to the name.

2 positiveInteger

The positiveInteger type is translated to TTCN-3 as a range-restricted integer in XSDAUX XSD:

type integer positiveInteger PositiveInteger (1 .. infinity) with {

extension variant "XSD:positiveInteger"

};

3 nonPositiveInteger

The nonPositiveInteger type is translated to TTCN-3 as a range-restricted integer in XSDAUX XSD:

type integer nonPositiveInteger NonPositiveInteger (-infinity .. 0) with {

extension variant "XSD:nonPositiveInteger"

};

4 negativeInteger

The negativeInteger type is translated to TTCN-3 as a range-restricted integer in XSDAUX XSD:

type integer nonPositiveInteger NegativeInteger (-infinity .. -1) with {

extension variant "XSD:negativeInteger"

};

5 nonNegativeInteger

The nonNegativeInteger type is translated to TTCN-3 as a range-restricted integer in XSDAUX XSD:

type integer nonNegativeInteger NonNegativeInteger (0 .. infinity) with {

extension variant "XSD:nonNegativeInteger"

};

6 long

The long type is 64bit based and translated to TTCN-3 as a plain longlong (defined in Annex D.2.1.3 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type longlong long_ Long with {

extension variant "XSD:long"

};

As “long” is already a keyword, an underscore has to be appended to the name.

7 unsignedLong

The unsignedLong type is 64bit based and translated to TTCN-3 as a plain unsignedlonglong (defined in Annex D.2.1.3 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type unsignedlonglong unsignedLong UnsignedLong with {

extension variant "XSD:unsignedLong"

};

8 int

The int type is 32bit based and translated to TTCN-3 as a plain long (defined in Annex D.2.1.2 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type long int Int with {

extension variant "XSD:int"

};

9 unsignedInt

The unsignedInt type is 32bit based and translated to TTCN-3 as a plain unsignedlong (defined in Annex D.2.1.2 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type unsignedlong unsignedInt UnsignedInt with {

extension variant "XSD:unsignedInt"

};

10 short

The short type is 16bit based and translated to TTCN-3 as a plain short (defined in Annex D.2.1.1 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type short short_ Short with {

extension variant "XSD:short"

};

As “short” is already a keyword, an underscore has to be appended to the name.

11 unsignedShort

The unsignedShort type is 16bit based and translated to TTCN-3 as a plain unsignedshort (defined in Annex D.2.1.1 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type unsignedshort unsignedShort UnsignedShort with {

extension variant "XSD:unsignedShort"

};

12 byte

The byte type is 8bit based and translated to TTCN-3 as a plain byte(defined in Annex D.2.1.0 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type byte byte_ Byte with {

extension variant "XSD:byte"

};

As “byte” is already a keyword, an underscore has to be appended to the name.

13 unsignedByte

The unsignedByte type is 8bit based and translated to TTCN-3 as a plain unsignedbyte (defined in Annex D.2.1.0 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type unsignedbyte unsignedByte UnsignedByte with {

extension variant "XSD:unsignedByte"

};

4 Float types

XSD float types are generally converted to TTCN-3 as subtypes of float. For an overview of the allowed facets please refer to Table 2 in clause ‎6.1. Following are details on the mapping of all float types of XSD.

1 decimal

The decimal type is translated to TTCN-3 as a plain float in XSDAUX XSD:

type float decimal Decimal with {

extension variant "XSD:decimal"

};

2 float

The float type is translated to TTCN-3 as an IEEE754float (defined in Annex D.2.1.4 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type IEEE754float float_ Float with {

extension variant "XSD:float"

};

As “float” is already a keyword, an underscore has to be appended to the name.

3 double

The double type is translated to TTCN-3 as an IEEE754double (defined in Annex D.2.1.4 of ETSI ES 201 873-1 [1]) in XSDAUX XSD:

type IEEE754double double Double with {

extension variant "XSD:double"

};

5 Time types

XSD time types are generally converted to TTCN-3 as pattern restricted subtypes of charstring. For an overview of the allowed facets please refer to Table 2 in clause ‎6.1. Following are details on the mapping of all time types of XSD.

1 duration

The duration type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD:

type charstring duration Duration (pattern "-?P([\d]+Y)#(0,)([\d]+M)#(0,1)([\d]+D)#(0,1) (T([\d]+H)#(0,1)([\d]+M)#(0,1)([\d]+(.[\d]+)#(0,1)S)#(0,1))#(0,1)") with {

extension variant "XSD:duration"

};

2 dateTime

The dateTime type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD

type charstring dateTime DateTime (pattern "-?[\d]#(4)-((0[1-9])|[10-12])-((0[1-9])|[10-31])T((0[1-9])|[10-23]):((0[1-9])|[10-59]):((0[1-9])|[10-59])(.[\d]+)#(0,1)([+-]?[\d:Z]+)#(0,1)") with {

extension variant "XSD:dateTime"

};

3 time

The time type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD:

type charstring time Time (pattern "((0[1-9])|[10-23]):((0[1-9])|[10-59]):((0[1-9])|[10-59])(.[\d]+)#(0,1)([+-]?[\d:Z]+)#(0,1)") with {

extension variant "XSD:time"

};

4 date

The date type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD:

type charstring date Date (pattern "-?[\d]#(4)-((0[1-9])|[10-12])-((0[1-9])|[10-31])([+-]?[\d:Z]+)#(0,1)") with {

extension variant "XSD:date"

};

5 gYearMonth

The gYearMonth type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD:

type charstring gYearMonth GYearMonth(pattern "[\d]#(4)-((0[1-9])|[10-12])([+-]?[\d:Z]+)#(0,1)") with {

extension variant "XSD:gYearMonth"

};

6 gYear

The gYear type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD:

type charstring gYear GYear (pattern "-?\d#(4)([+-]?[\d:Z]+)#(0,1)") with {

extension variant "XSD:gYear"

};

7 gMonthDay

The gMonthDay type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD:

type charstring gMonthDay GMonthDay (pattern "--((0[1-9])|[10-12])-((0[1-9])|[10-31])([+-]?[\d:Z]+)#(0,1)") with {

extension variant "XSD:gMonthDay"

};

8 gDay

The gDay type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD:

type charstring gDay GDay (pattern "---((0[1-9])|[10-31])([+-]?[\d:Z]+)#(0,1)") with {

extension variant "XSD:gDay"

};

9 gMonth

The gMonth type is translated to TTCN-3 using the following pattern-restricted charstring in XSDAUX XSD:

type charstring gMonth GMonth (pattern "--((0[1-9])|[10-12])([+-]?[\d:Z]+)#(0,1)") with {

extension variant "XSD:gMonth"

};

6 Sequence types

XSD sequence types are generally converted to TTCN-3 as a set record of their respective base types. For an overview of the allowed facets please refer to Table 2 in clause ‎6.1. Following are details on the mapping of all sequence types of XSD.

1 NMTOKENS

The NMTOKENS type is mapped to TTCN-3 using a set record of construct of type NMTOKEN in XSDAUX XSD:

type set record of NMTOKEN NMTOKENS with {

extension variant "XSD:NMTOKENS"

};

2 IDREFS

The IDREFS type is mapped to TTCN-3 using a set record of construct of type IDREF in XSDAUX XSD:

type set record of IDREF IDREFS with {

extension variant "XSD:IDREFS"

};

3 ENTITIES

The ENTITIES type is mapped to TTCN-3 using a set record construct of type ENTITY in XSDAUX XSD:

type set record of ENTITY ENTITIES with {

extension variant "XSD:ENTITIES"

};

4 QName

The QName type is translated to TTCN-3 as a plain charstring below in XSDAUX XSD:

type charstring QName with {

extension "XSD:QName"

};

type record QName

{

AnyURI uri optional,

NCName name

}with {

variant "XSD:QName"

};

When encoding an element of type QName (or derived from QName), if the encoder detects the presence of an URI and this is different from the target namespace , the folowing encoding results (the assumed target namespace is ):

type record E14a

{

QName name ,

integer refId

}

template E14a t_E14a:=

{

name:={

uri:=””,

name:=”someName”

},

refId:=10

}

ns:someName

10

It is not legal to specify length restrictions for QName types.

7 Boolean type

The boolean type is mapped to TTCN-3 using as a boolean in XSDAUX XSD:

type boolean boolean_ Boolean with {

extension variant "XSD:boolean"

};

As “boolean” is already a keyword, an underscore has to be appended to the name. During translation of XSD boolean values it is necessary to handle all four values that XSD allows for booleans (“true”, “false”, “0”, and “1”); “true” and “1” have to be mapped to true, whereas “false” and “0” have to be mapped to false. This will be realized using the “text” encoding instruction:

type Boolean MyBooleanType with {

variant "text ‘true’ as ‘1’";

variant "text ‘false’ as ‘0’";

};

8 anyType, anySimpleType types

anySimpleType can be considered as the base type of all primitive datatypes, while anyType is the base type of all complex definitions and the anySimpleType.

anySimpleType is translated as an XML compatible restricted subtype of the universal charstring in XSD:

type XMLCompatibleString AnySimpleType with {

variant "XSD:anySimpleType"

};

while anyType is translated into XML content opaque to the codec:

type record AnyType

{

record of String attr,

record of String elem_list

} with {

variant "XSD:anyType";

variant "anyAttributes ‘attr’";

variant "anyElement ‘elem_list’”;

};

Without support for mixed content. See also ch.7.7 (anyAttributes, anyElement).

Mapping XSD components

After mapping the basic layer of XML Schema (i.e. the built-in types) a mapping of the structures has to follow. Every structure that may appear, globally or not, needs to have a corresponding mapping to TTCN-3.

The guiding principle of mapping is alignment to ITU-T Rec.X.694: all structures are the result of two subsequent transformations applied to the XSD Schema: first , transformations descibed in ITU-T Rec.X.694 , then transformations described in ETSI standard ES 201 873-7.

1 Attributes of XSD component declarations

Table 5 and Table 6 contain an overview about the major attributes that are encountered during mapping. It is not complete: special attributes that are only used by a single XSD component are described in the corresponding subclauses. Table 5 and Table 6 show which attributes are needed to be evaluated when converting to TTCN-3, depending on the XSD component to be translated.

Table 5: Attributes of XSD component declaration #1

|[pic] |element |attribute |simple |complex |simple |complex |group |

| | | |type |type |content |content | |

|id |( |( |( |( |( |( |( |

|final |( | |( |( | | | |

|name |( |( |( |( | | |( |

|maxOccurs |( | | | | | |( |

|minOccurs |( | | | | | |( |

|ref |( |( | | | | |( |

|abstract |( | | |( | | | |

|block |( | | |( | | | |

|default |( |( | | | | | |

|fixed |( |( | | | | | |

|form |( |( | | | | | |

|type |( |( | | | | | |

|mixed | | | |( | |( | |

Table 6: Attributes of XSD component declaration #2

| |

|V1.0.0 |March 2004 |ToC |

|V1.0.0 |March 2005 |First stable draft |

|V1.0.0 |July 2006 |Corrected Draft |

|V1.0.0 |October 2006 |Finalised Draft |

|V1.0.0 |May 2007 |Aligned with ITU-T Rec. X.694 |

-----------------------

type

facet

Table 3: Translation of special characters

|XSD |TTCN-3 |

|. |? |

|\s |[ς\t\n\r] |

|\S |[^ς\t\n\t] |

|\d |\d |

|\D |[^\d] |

|\w |\w |

|\W |[^\w] |

|\i |[\w\d:] |

|\I |[^\w\d:] |

|\c |[\w\d.\-_:] |

|\C |[^\w\d.\-_:] |

Table 4: Translation of quantifiers

|XSD |TTCN-3 |

|? |#(0,1) |

|+ |#(1, ) |

|* |#(0, ) |

|{n,m} |#(n,m) |

|{n} |#(n) |

|{n ,} |#(n, ) |

comp䱫䲊䲏䲐䳈䳯䳳䳴䴎䴬䴱䴲䵤䶊䶏䶐䶰䷐䷕䷖不丵为主ì���Ù���ì���Ù���ì���Ù���ì���Ù���onent

attribute

component

attribute

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download