X.693 specifies XER ("XML Encoding Rules"). There are three variants of XER given: BASIC-XER (often just XER for short), canonical XER, and EXTENDED-XER. Into this mix, Objective Systems has added its own encoding rules which we'll call OSys-XER. OSys-XER is very similar to XER, but has a few variations that are meant to produce XML documents more closely aligned with what you might get if you were using XML Schema to specify your abstract syntax. Generally, OSys-XER produces fewer tags. The differences between these two sets of encoding rules are discussed in more detail below.
ASN1C supports BASIC-XER, canonical XER, and OSys-XER. It has for some time supported EXTENDED-XER via direct compilation of XSD. In version 6.5.0, we have begun to add direct support for EXTENDED-XER by adding support for some of the XER encoding instructions. Nonetheless, EXTENDED-XER is most fully support today via direct compilation of XSD. By compiling XSD, you can obtain behavior much the same as with OSys-XER, and more.
Prior to version 6.5.1, ASN1C generated two different styles of code and had two different runtime layers for the various XML encoding rules. In support of XER (basic and canonical), there was the XER style of generated code and the XER runtime. In support of OSys-XER and extended-XER (via direct compilation of XSD), there was what we called simply the XML style of generated code and the XML runtime. These two styles of code generation had different encode and decode method signatures, and used different XML parsing techniques (SAX vs. pull-parser). As of version 6.5.1, these have been merged together. The old style of XER code generation has now been deprecated. XER is now supported using the same style of code and the same runtime that was previously used for OSys-XER and extended-XER (via direct XSD compilation).
Depending on the circumstances, the generated code may support more than one set of
encoding rules. In these cases, the OSASN1XER and
OSXMLC14N flags (set using rtxCtxtSetFlag) are
used to choose, at runtime, which encoding rules to follow. OSASN1XER
should be set when using BASIC-XER, canonical XER, or EXTENDED-XER. For canonical XER,
OSXMLC14N must also be set. The table below describes the
possibilities.
Note that you may use the -xsd switch when generating XML encoders and decoders. The XML schema produced from the ASN.1 specification using the -xsd switch can be used to validate the XML messages generated using the XML encode functions. Similarly, an XML instance can be validated using the generated XML schema prior to decoding.
| Compiler Invocation | What is Generated |
|---|---|
| -xer flag is used to compile ASN.1 without XER encoding instructions |
Generated code supports BASIC-XER, canonical XER, and OSys-XER. Set
the flags described above to choose the desired encoding at runtime.
Generated PDU methods (e.g. ASN1C_MyType::Decode,
ASN1C_MyType::Encode, XmlEnc_MyType_PDU, XmlDec_MyType_PDU) will automatically set -xsd produces schema that validates BASIC-XER encodings. |
| -xer or -xml flag is used to comple ASN.1 with supported XER encoding instructions (if any instructions are not supported, all instructions are ignored, and the above entry in this table applies) |
Generated code supports EXTENDED-XER only. You should set the
-xsd produces schema that validates EXTENDED-XER encodings. As of this writing, this is not fully supported. |
| -xml used to compile ASN.1 |
This is the same as the first entry (using -xer) except that the
generated PDU methods will NOT automatically set
-xsd produces schema that validates OSys-XER encodings. |
| -xml used to compile XSD | Generated code supports EXTENDED-XER only. You should set the
OSASN1XER flag. If you are using the PDU methods, it
will be automatically set for you. |