[
Lists Home |
Date Index |
Thread Index
]
Michael Champion wrote:
>
> Trouble is, you can't make sense of an ASN.1 message without
> having the
> schema, and I mean the EXACT schema, used to generate it. That's
> (oops, smell of impending flames <grin>) the value
> proposition for XML
> in a nutshell, IMHO, and why it is used in all those projects Simon
> mentioned where ASN.1 is, on paper, better suited.
Well, if you use the XML encoding rules (EXTENDED-XER), an ASN.1 message
*is* an XML document. So you can make sense of the ASN.1 message even if
you don't know the exact schema.
This doesn't hold for the binary encoding rules (e.g., PER), because they
are not as self-describing as XML. When you re-encode an XML message in
PER, you reduce the length of the message but become totally dependent on
the exact knowledge of the schema. When you re-encode a PER message in XML,
you become self-describing again.
ASN.1 allows you to use XML or PER or BER (etc.) on a
transmission-by-transmission basis. Nothing prevents you from *always*
using XML as the encoding, if you are concerned about tolerating small
variations in the messages. Or you can use XML for some exchanges and PER
for others (where you can be sure that the schema will be respected). A
protocol designer or a system designer can just choose what is the most
appropriate selection of encoding rules (which may include XML, binary, or
both). A property of ASN.1 is that the application's view won't be affected
by those decisions (because applications operate on the abstract values, not
on the encodings).
Alessandro Triglia
|
