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.
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.
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.
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 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.