Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
