1 / 11

INTEGRATING XML INTO TTCN-3 MTS#45, 45TD35

INTEGRATING XML INTO TTCN-3 MTS#45, 45TD35. L. M. Ericsson. Why is this interesting at all?. The XML is an explosively spreading technology, standing at the core of Web Services XML is also becoming more and more important in convergent telecom/datacom networks (3G). TTCN-3 code (templates).

sean-fox
Download Presentation

INTEGRATING XML INTO TTCN-3 MTS#45, 45TD35

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. INTEGRATING XML INTO TTCN-3 MTS#45, 45TD35 L. M. Ericsson

  2. Why is this interesting at all? • The XML is an explosively spreading technology, standing at the core of Web Services • XML is also becoming more and more important in convergent telecom/datacom networks (3G)

  3. TTCN-3 code (templates) XSD Schema XML document What is aimed for? • An integration similar to the ASN.1 integration into TTCN-3: XML codec import

  4. ASN.1 code plus E-XER XSD Schema XML document TTCN-3 code (templates) Current status of integration • The ITU recommendation X.694, published in 2004, describes mapping of XML Schema definitions into ASN.1 code and E-XER encoding instructions. XML test implementations based on importing ASN.1 obtained from XML Schema into TTCN-3 test suites have been written and are being used: conversion import encode

  5. Conversion principles • A standard describing direct usage of XML from TTCN-3 should offer seamless migration from the ASN.1 based implementations to TTCN-3 based ones. • It shall allow effective working and tool implementation. • Part-9 of the TTCN-3 standard shall be consistent with other parts of the • TTCN-3 standard (pls. note, that Part-7 will have to be completed with the XML-related ASN.1 structures at some point in time) and • ITU-T Recommendations (otherwise this part will be refused • Shall be future-proof in sense of not making the use of Fast web services apriori (this may come up e.g. in 3GPP but also in other areas at any point in time)

  6. Conversion principles (cont.) • Name mapping and namespace handling shall be explicit and efficient • The XML space cannot be mapped directly into TTCN-3 (or ASN.1 ) code (Example: TTCN-3 cannot distinguish between “element” and “attribute”); hence, part of the information will be mapped into the code, part of it into encoding instructions (in their functionality similar to E-XER instructions in ASN.1)

  7. Advantages of aligning • The ITU X.694 is an industry-proven, robust and detailed standard, allowing a precise conversion; alignment would allow quick convergence towards a stable solution • XML can be used and is being used intensively with TTCN-3 via the double conversion pathXSD->ASN.1->TTCN-3 • It would ease migration from ASN.1 based solutions to direct TTCN-3 mapping, making TTCN-3 a more attractive option

  8. Disadvantages of aligning • The ASN.1 conversion rules would leave their imprint on the XML/TTCN-3 conversion. In some cases this might be even interpreted as a beneficial style constraint- capitalized type names for instance; in some cases alignment leads to not-so-obvious TTCN-3 structures.

  9. Advantages of an independent conversion • Not so many visible

  10. Disadvantages of an independent conversion • A painful re-invention of the wheel • Migration across TTCN-3/ASN.1/XML boundaries made difficult • Draft in 43TD07 would make using XML from the TTCN-3 code inefficient in case of implicit mapping -> user’s could reject using it with high probability • As no mandatory name mapping is given in 43TD07, code re-usability and conversion efficiency would be sacrificed (e.g. between TISPAN-3GPP, using standard test suites by industrial members, industrial members to contribute to standardization etc.) • Draft in 43TD07 does not contain consistent information for message encoding -> no automatic codec generation is possible, painful codec maintenance time and cost

More Related