1、SAE Technical Standards Board Rules provide that: This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirelyvoluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefrom
2、, is the sole responsibility of the user.SAE reviews each technical report at least every five years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions.Copyright 2003 SAE InternationalAll rights reserved. No part of this publication may be re
3、produced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying,recording, or otherwise, without the prior written permission of SAE.TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada)Tel: 724-776-4970 (outside USA)Fax: 724-77
4、6-0790Email: custsvcsae.orgSAE WEB ADDRESS: http:/www.sae.orgSURFACEVEHICLESTANDARDJ2630ISSUEDDEC2003Issued 2003-12Converting ATIS Message Standards From ASN.1 to XMLForewordThis document provides a set of conversion rules and recommendations which can be applied to ASN.1to produce XML schema output
5、s. These rules were developed primarily for use with the ITS message setsdeveloped by SAE and other standards organizations. However, these rules may also apply to other ITS messagesets developed by SAE and other standards organizations. The results of applying these rules (a set of XMLschema encodi
6、ngs) is published elsewhere (typically with the source standard). In the case of SAE standards theresults of applying these rules can be found in the revised edition of SAE J2354.TABLE OF CONTENTS1. Scope . 22. References . 33. Definitions. 44. Rules for Converting an ASN.1 Message Set Definition to
7、 an XML Schema. 54.1 Defining a Simple Type in Terms of a Basic Type. 64.2 Defining Basic INTEGER Types . 64.3 Defining INTEGER Types with Minimum and Maximum Values. 74.4 Defining String Types of Minimum and Maximum Length 74.5 Defining String Types of Fixed Length 84.6 Defining ENUMERATED Types 94
8、.7 Defining a Type Definition Embedded in an Element Definition . 114.8 Defining a Complex Type as a SEQUENCE of Elements. 114.9 Defining a Complex Type as a CHOICE of Elements. 124.10 Defining a Complex Type as a SEQUENCE OF Named Types 124.11 Defining a Complex Type as a SEQUENCE OF a Named Type w
9、ithMinimum and Maximum Number of Elements 134.12 Defining a Complex Type as a SEQUENCE OF an Unnamed Type. 134.13 Defining Elements as Instances of Existing Basic Types . 144.14 Defining Elements as Instances of User-Defined Types. 144.15 Defining Elements as Instances of In-Line Defined Types .154.
10、16 Defining BIT STRING Elements . 164.17 Defining OCTET STRING Elements. 174.18 NULL Elements 194.19 Object Identifer (OID) Elements . 19SAE J2630 Issued DEC2003-2-4.20 Optional Elements 194.21 Handling Comments .204.22 Commonly Repeated Element204.23 Defining an Element of a Type Defined in a Diffe
11、rent Schema.214.24 Defining Top-Level Elements 214.25 Beginning and Ending the Schema 225. Discussion of Selected Conversion Rules 225.1 Methods of Defining ENUMERATED Elements 225.2 Alternate Methods of Defining Mixtures of Text Strings and ENUMERATED Elements .245.3 Alternate Method of Defining BI
12、T STRINGSs.265.4 Treatment of IA5String Contents.275.5 Treatment of OCTET STRINGs 275.6 Treatment of Manual ASN.1 Tag .275.7 Treatment of Long ASN.1 Names .285.8 Treatment of ASN.1 Comments 285.9 Use of XML Namespaces to Point to Types Defined in Other Standards .295.10 Expressing the Resulting Sche
13、ma in a Standard .316. New Types Defined for the SAE ATIS J2353/2354 Schema .316.1 Binary Type .326.2 OctetString Type .326.3 NumericString Type 326.4 BoundedString Type .336.5 UndefinedElement Type337. A Complete Example of the Rules in Use.348. BIBLIOGRAPHY .40TABLE 1 XML TRANSLATION BASIC TYPES 6
14、TABLE 2 XML TRANSLATION RECOMMENDATIONS.6TABLE 3 RANGES FOR XML INTEGER TYPES .61. ScopeThis SAE Standard presents a set of rules for transforming an Abstract Syntax Notation (ASN.1)message set definition into an eXtensible Markup Language (XML) schema. The result is intended to be astand-alone XML
15、Schema that is fully consistent with an existing ASN.1 information model. This is a differentgoal from other related work by other standards bodies developing a set of XML encoding rules for ASN.1 orASN.1 encodings for XML Schema. These rules were initially developed in order to produce an XML schem
16、afor the SAE ATIS standard. While other standards may also choose to use these rules, the rules may not beapplicable for all environments.The goal for these transformation rules is twofold. The first goal is to provide a uniform set of such rules that allinterested parties can use. The second goal i
17、s to use such rules to define an adopted schema for travelerinformation that reflects the preferred translation of ASN.1 message sets to XML for use by ITS systemimplementers. The first goal is met by this document. The second goal is met by employing this document toproduce XML information as part
18、of the periodic re-balloting of the SAE ATIS standard. This is a parallelstandards effort with this document.11. At this time a numer o technical data formatting issues are being resolved as part of the re-issue of SAE J2354 (drafts available at the commit-tee forum site t http:/www.SAE.org/). The X
19、ML productions will be included in this parallel effort. SAE J2353 and the message set contents of other ITS standards are being integrated within this single standard to produce a composite data dictionary of all SAE ITS messages.SAE J2630 Issued DEC2003-3-These rules were developed as part of the
20、process to draft an XML version of the ATIS data element andmessage set standards. The original effort focused upon the needs found in the currently adopted October2000 SAE J2354 standard for ATIS message sets. SAE J2354 makes extensive use of elements from theITETMDD work and from ITE-TCIP work. In
21、 addition, the draft “Event Report Message” (ERM) portion of theMessage Sets for External Traffic Management Center Communication (MS/ETMCC) standard was alsoexamined and translated. Message and data elements from the IEEE Incident Management standard (IEEE1512-2000) were also examined. By this effo
22、rt, every major message set of ITS was considered to somedegree to ensure that the resulting translations could be successfully employed by others toward a commonresult. It is intended that the resulting ATIS schema will be voted on as an SAE ATIS standard. Otherstandards-developing organizations ma
23、y also choose to use these rules; however, it is recognized thattranslations may not be necessary in some environments and that these rules may not be applicable to allenvironments within ITS. It is left to each standards-development organization to make such determinations fortheir specific environ
24、ments.Section 4 is the complete set of conversion rules. An example of use for each rule is given, showing an originalASN.1 definition, the resulting XML schema definition, and a sample XML document element where applicable.Section 5 of this document discusses the background of some non-obvious conv
25、ersion rules presented inSection 4.2These include methods of handling the XML representation of enumerations, octet strings, and bitstrings. Section 5 also describes how XML namespaces can be used to point to types defined in the TrafficManagement Data Dictionary (TMDD), the Transit Communications I
26、nterface Profiles (TCIP) standard, theLocation Reference Message Set (LRMS), or the International Traveler Information Systems (ITIS) phrase lists.It also discusses additional translation refinements proposed for the conversion of the ATIS message standard.Some omissions in the SAE standards require
27、d new types to be defined in order to have a valid XML schema.In addition, some new types must be defined to implement the representation of octet strings and bit strings.These changes are documented in Section 6. In the currently adopted revision of the standard the use of inlinedefinitions rather
28、than the more proper use of formal Type Definitions is also a challenge for conversion.Section 6 also documents a number of common types that were defined globally at the start of the schemarather than being redefined identically, in-line multiple times in the schema.Section 7 presents a sizable sam
29、ple ASN.1 definition and the corresponding XML schema. The sampleillustrates a large number of the conversion rules.2. References2.1 Applicable PublicationsThe following publications form a part of this specification to the extent specifiedherein.2.1.1 SAE PUBLICATIONSAvailable from SAE, 400 Commonw
30、ealth Drive, Warrendale, PA 15096-0001.SAE J2353Data Dictionary for Advanced Traveler Information Systems (ATIS)SAE J2354Message Sets for Advanced Traveler Information Systems (ATIS) Readers are advised that these two documents are now being updated to reflect current data registryformats and curren
31、t ITS industry practices. J2354 will also include an XML schema derived from theASN.1 found in the revised documents meeting the translation rules of this standard.2. This document deals only with the final set of recommended rules. An earlier set of preliminary rules, refined by group experience, i
32、s docu-mented in several informal reports. This earlier draft is available at the committee forum site at http:/www.SAE.org.SAE J2630 Issued DEC2003-4-2.1.2 ITE PUBLICATIONSAvailable from Institute for Transportation Engineers (ITE), 1099 14th Street, NW, Suite300 West, Washington, DC 20005-3438 Tel
33、ephone: 202-289-0222 ite_staffite.org Transit CommunicationsInterface Profiles (TCIP) Framework Standard (NTCIP 1400 Draft), December 2000.Transit Communications Interface Profiles (TCIP) Scheduling Business Area Standard FrameworkStandard (NTCIP 1403 Draft), December 2000.Transit Communications Int
34、erface Profiles (TCIP) Passenger Information Business Area StandardFramework Standard (NTCIP 1403 Draft), December 2000.Standards for Functional Level Traffic Management Data Dictionary (TMDD), Standard No. TM1.01.4.Message Sets for External Traffic Management Center Communication (MS/ETMCC) ITE-AAS
35、HTO-TM2.01 August 2000.2.1.3 PUBLICATIONXML Definitions Available on the Internet from the URLs below.World-Wide-Web Consortium Definition of XML: http:/www.w3.org/XML/World-Wide-Web Consortium Definition of XML Schemas: http:/www.w3.org/XML/Schema Consisting ofParts Two and Three. Part One is infor
36、mative and is listed in the Bibliography3. Definitions3.1 Application ProgramIn the context of this document, any process beyond the XML validation, which may ormay not be done by the top most application. For example it is common to employ intermediate levels to furtherprocess the XML source and ma
37、nipulate it based on knowledge of the message structures or tag data.3.2 ATISAdvanced Traveler Information Systems, specifically the SAE J2353 and J2354 standards of ITS dataelements and message sets. As a slang term, this has become the common term to refer to all the SAE effortsin developing ITS m
38、essages.3.3 ERMEvent Reporting Message. A portion of the TMDD message set family which was develop first by ruralstates and has now been added to the most current draft of the ITE committee message set work.3.4 FalseIn the context of this standard and XML, the Boolean value 0 is also defined as Fals
39、e.3.5 IEEEThe Institute of Electrical and Electronics Engineers, a New York not-for-profit corporation engaged indeveloping standards. One of the standards developing organizations. A party to the cooperative developmentagreement of the FHWA to develop ITS standards.3.6 IMIncident Management, a slan
40、g term for the IEEE 1512-2000 and related family of standards that deal withexchanges of message sets between centers involved in an incident.3.7 ITEThe Institute of Traffic Engineers, a not-for-profit corporation engaged in developing standards. One ofthe standards developing organizations. A party
41、 to the cooperative development agreement of the FHWA todevelop ITS standards.3.8 LRMSLocation Referencing Message Set, a portion of ITS message structures developed under the FHWAcooperative agreements and now undergoing standardization by the SAE in its second major revision. TheLRMS handles all o
42、f the spatial portions of ITS messages and is therefore widely re-used by other standards.3.9 TCIPTransit Communications Interface ProfilesSAE J2630 Issued DEC2003-5-3.10 TMDDTraffic Management Data Dictionary. The data dictionary developed by the ITE as part of its work onmessages used between and
43、within traffic management centers. Also often used as a slang term for the boththe data elements and the messages developed in that effort. The SAE ATIS message set reuses these dataelements as well.3.11 TrueIn the context of this standard and XML, the Boolean value 1 is also defined as True.3.12 XM
44、LeXtensible Marked Language3.13 XSLeXtensible Stylesheet Language4. Rules for Converting an ASN.1 Message Set Definition to an XML SchemaThe following is a list of rulesorganized as pseudo-code instructions for converting an ASN.1 definition to an XML schema. It is far fromcomplete for anything that
45、 may appear in ASN.1, but it is believed complete for everything that appeared in theATIS message sets standard as well as several other standards found in ITS.There are many ways such a conversion could be performed; this approach attempts to be as direct aspossible. For example, almost no user-def
46、ined attributes are used, and all data structures are preserved. Theinformation contained in the transmitted document is identical, and the data structures are clearly equivalent.One goal is that a program with knowledge of an ASN.1 definition set and the XML schema produced from it bythese rules sh
47、ould be able to convert a conforming XML document into a conforming ASN.1 encoding and viceversa.3A second goal, however, is that developers of XML-based interfaces and the software they develop willnot require knowledge or use of ASN.1.Note: In ASN.1, formally defined type definitions begin with a
48、capital letter and identifiers for those types beginwith a lower case letter. This conversion to XML preserves this convention, although there is no rule in XMLrequiring this convention. In fact, ebXML guidelines recommend that the names of all types and elementsshould begin with a capital letter, w
49、hile the names of attributes should begin with a lower case letter. The SAEATIS committee should consider whether to retain the lower case starting letter convention. In any event,shortening of some ASN.1 names when used as tags may be adopted.The examples are taken from fragments of SAE ATIS, ITE TMDD, and IEEE IM standards, but the precisestructures have been modified at times to serve as an example more clearly. Explanatory comments from theASN.1 have been removed to conserve space. Consult the governing standard for correct structures and usecommentary. T
