|
XML encoding rules (XER) for ASN.1
The XML value notation for ASN.1 types makes it possible to define values
using XML markup in which the element tags are derived from the ASN.1 type names
and identifiers present in an ASN.1 specification.
Instances of XML value notation can appear in an ASN.1 module and are suitable for
display in an XML-enabled browser. This feature has been added as a new value notation
for ASN.1 types in the 2002 edition of the base ASN.1 standard (ITU-T
X.680 | ISO/IEC 8824-1
).
|
|
The XML value notation is also the base for a new set of encoding rules for ASN.1,
the "XML Encoding Rules" (XER), published as a new standard (ITU-T X.693 | ISO/IEC 8825-4). Except for a few minor
differences (such as the addition of a prolog), the XML produced by the XML Encoding
Rules is the same as the XML value notation. Both a canonical (called CXER and used,
e.g., for digital signatures) and a non-canonical variant of the XML Encoding Rules
have been defined.
|
|
To vary the XML encoding produced by default by a Basic-XER tool, XER encoding instructions
can be added to the ASN.1 modules in two forms: either as prefix notation in front
of types (in the same way as BER encoding instructions are added as tags in front
of types) or as an encoding control section at the end of the ASN.1 module. The
encoding is then called EXTENDED-XER or E-XER.
There are XER encoding instructions for:
- attributes vs. elements;
- mixed content;
- variable-order sequences (those marked with "*" in an XML Schema
and consisting in a group of elements whose order in the instance doesn't matter);
- removing wrappers around multiple occurrences of things;
- CHOICEs corresponding to XSD type derivation hierarchies;
- CHOICEs corresponding to XSD element substitution groups;
- CHOICEs corresponding to XSD unions;
- SEQUENCE OFs corresponding to XSD lists;
- support of wildcards;
- and so on.
All these features are supported by an XER-specific notation in the ASN.1 schema,
which affects EXTENDED-XER encodings but does not affect BER/DER/PER encodings.
|
|
One of the main objectives of this XML-related work is to allow ASN.1 specifications
(modules) to be used as ASN.1 schemas against which XML documents can be
validated. As a result, the ASN.1 language now competes with other XML schema languages
such as XML Schema and
RELAX NG , but it has some additional benefits over them.
ASN.1 is seen as a notation that has significant advantages over other XML schema
notations in both the simplicity of the notation and the ease of mapping it to C,
C++ and Java data structures that can enable the rapid implementations of applications
to support (XML and other) communications defined using that notation.
The ease of such mappings is due to its clear specification of the abstract values
that ASN.1-defined messages can contain, rather than concern solely with the syntactic
(XML or binary) form of such messages, which other schema definition notations (or
use of ABNF) are primarily concerned with.
Protocols specified in ASN.1 can take advantage of the compact standardized ASN.1
encodings (such as the Packed Encoding Rules) to exchange messages over bandwidth-constrained
links, but the same abstract data can be encoded in XML with no effort and sent
to an XML-enabled browser for display (possibly using style sheets).
|
|
BER- or PER-generated messages described by ASN.1 are a small fraction of the size
of XML messages. This enables content-rich Web pages, video and other data-intensive
messages to travel where it might not otherwise be able to go, namely, the narrow
confines of wireless broadband.
|
|
The application of security functions to ASN.1-defined data is well-established,
and the lack of repetitive text sequences, and avoidance of redundancy and general
text orientation in its Packed Encoding Rules (PER) make non-disclosure functions
much less vulnerable to attack than direct encryption of XML text.
|
|
ASN.1 Mailing list
Any questions related to ASN.1/XML (but not to any particular ASN.1 tool) can be
sent to asn1@asn1.org
.
|
|
