[
Lists Home |
Date Index |
Thread Index
]
Bob Wyman wrote:
>
> Today, now that we've got an updated X.693 and vendor
> support for it, these folk can simply use an E-XER
> encoder/decoder and they'll have XML moving in an out of the
> systems that used to only support binary encodings. And, they
> won't have to change any code other than the one or two lines
> of code that tell the ASN.1 layer which encoder/decoder to
> use. Thus, implementors can produce encoding-independent
> implementations that will accept either binary encodings or
> XML encodings. This means that both new and old systems can
> be supported with the same code base.
> If these standards groups are smart, they won't force a
> complete switch over to XML. What they should do is agree on
> the ASN.1 schemas and then allow either XML or PER to be used
> for interchange. There is no reason to insist on one or the
> other. In this way, if someone ends up having a requirement
> for binary encodings, they won't have to go change the
> standard or produce a non-conforming implementation.
Allow me to reword (partially).
1) If you have an existing ASN.1 schema and want to get XML on the wire, you
don't need to translate your ASN.1 schema to W3C XML Schema - just
**select** EXTENDED-XER as the encoding rules.
You don't need to change anything in the application code (apart from
selecting EXTENDED-XER) or in the ASN.1 schema.
2) If you are not happy with the default XML encoding (no namespaces, no
attributes, no mixed content, presence of unnecessary element wrappers,
etc.), you can add "XER encoding instructions" to the ASN.1 schema.
XER encoding instructions modify the XML encodings without changing the
meaning of the abstract type definitions. By using them, you can get
attributes, namespaces, mixed content, QNames, space-separated lists,
unions, xsi:nil, xsi:type, variable-order model groups, etc.
Since the presence of XER encoding instructions does not change the meaning
of the abstract type definitions, the application's view will not be
affected and so there is no need to change anything in the application code.
Also, the BER/PER encodings will not be affected by the XER encoding
instructions that you have added to the schema. In essence, you have
enabled your existing ASN.1 schema to produce "rich" XML encodings while
still interoperating with the original schema in binary.
Alessandro Triglia
> bob wyman
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an initiative of OASIS
<http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
