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
csharp/sample_xer/EmployeeEXER, should you need to see an
example.