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.)
As noted above, when generating code for EXTENDED-XER, you will be working with the "XML" runtime, as oppposed to the "XER" runtime. This makes coding for EXTENDED-XER slightly different from coding for XER:
You will use Asn1XmlEncoder instead of Asn1XerEncoder
You will supply the name of the element when encoding a value. Typically, this will be the name of the ASN.1 PDU type.
Finally, there is a sample reader and writer program in java/sample_xer/EmployeeEXER, should you need to see an example.