EXTENDED-XER

EXTENDED-XER (specified in X.693) allows you to vary the XML encoding of ASN.1 by using XER encoding instructions. ASN1C supports EXTENDED-XER in two different ways: by compiling XSD and by compiling ASN.1 with XER encoding instructions. Support for XER encoding instructions in ASN.1 is limited.

This section relates to our support for XER encoding instructions. If some features you need are not supported, you might consider using direct compilation of XSD.

How to Generate Code for EXTENDED-XER

If your ASN.1 contains XER encoding instructions, ASN1C will automatically generate code for EXTENDED-XER instead of BASIC-XER. This is true whether you use -xer or -xml on the command line. If, however, any unsupported encoding instructions are found, ASN1C will ignore all XER encoding instructions, since it would not be capable of supporting EXTENDED-XER for that specification.

Supported Instructions and Brief Summary

ASN1C supports these instructions: ATTRIBUTE and BASE64. Very brief summaries of the effects of these instructions follow.

  • ATTRIBUTE: This instruction causes a component of a sequence to be encoded as an XML attribute.

  • BASE64: This instruction causes octet strings to be encoded in a base64 representation, rather than a hexadecimal one.

Limitations

The following are limitations related to EXTENDED-XER:

  • For BASE64: ASN1C only supports BASE64 on octet strings. Using BASE64 with octet stings having contents constraints, open types, or restricted character strings is not supported.

  • For encoder's options: ASN1C decoders do not support the following encoder's options allowed by EXTENDED-XER:

    • encoding named bits as empty elements

    • encoding named numbers as empty elements

  • Enforcement of Encoding Instruction Restrictions: ASN1C does not check that you are using encoding instructions properly. Misapplication of encoding instructions has undefined results. For example, X.693 does not generally allow ATTRIBUTE to be applied to a sequence type (there are a few cases where it can be); such an application produces malformed XML.

    In particular, when applying ATTRIBUTE to a restricted character string type, the type should be restricted to exclude the control characters listed in X.680 15.15.5, since these control characters are encoded as empty elements. (Another solution would be to use ATTRIBUTE and BASE64 together, except that ASN1C does not currently support BASE64 for restricted character strings.) ASN1C will not enforce this rule, but you will get malformed XML if you try to encode a string having control characters as an attribute.

  • XSD Generation: The -xsd switch does not currently generate XSD that can be used to validate EXTENDED-XER encodings. (Actually, in the worst cases, it is not possible to produce XSD that validates precisely the set of valid EXTENDED-XER encodings; the closest approximations would either fail to reject some invalid encodings or fail to accept some valid encodings. This is a result of the encoder's options, which can produce mixed content models and XML Schema's limited abilities to constrain mixed content models.)

Working with generated EXTENDED-XER code

Working with the code generated for EXTENDED-XER is the same as for XER, except that you must be sure to have set the OSASN1XER context flag. The generated PDU encoders and decoders should automatically set OSASN1XER for you, but if you are not using these methods, you should be sure to set the OSASN1XER flag yourself, using rtxCtxtSetFlag.

For encoding and decoding, you will work with the "XML" (as opposed to the "XER") runtime. This is actually true for BASIC-XER also, unless you are using the deprecated, old style XER.

Finally, there is a sample reader and writer program in c/sample_xer/employee-exer and cpp/sample_xer/employee-exer, should you need to see an example.