Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Fast text output from SAX?
 Stephen D. Williams wrote: > ASN.1 is based on certain assumptions that are not > true of every situation that needs better efficiency > than XML 1.1. As an example shoehorning self-description > into a format that was explicitly designed in the > opposite way doesn't seem like the best path, to me. Clearly, you do not understand ASN.1 very well. First, ASN.1 is just a schema language -- it is not an encoding format. But, it is a schema language that was first used to define self-describing binary data streams. These were encoded using the (Basic Encoding Rules) which relied on "tag-length-value" encoding. (i.e. each value is tagged with its type and its length). You can think of BER as ASN.1's own "XML". i.e it is very easy to read (assuming you're comfortable with binary and have a schema to look up the non-standard type numbers), very easy to write, and it is bulky (because of all the tags and lengths). Note: There is even the equivelant of "namespaces" in ASN.1... These are driven off an ISO maintained OID (object identifier) tree. Thus, you can ensure that your tags are globally unique. (Admittedly, many will argue that the OID method is unnecessarily cumbersome...) Other encoding rules for ASN.1 have been defined. For example, there is XER (XML Encoding Rules -- basically BER with text tags...), CER (Canonical Encoding Rules) and DER which are useful when doing signed stuff, and PER (Packed Encoding Rules) which are highly efficient and compact. If you only look at PER, you might get the idea that ASN.1 codings aren't self-describing. That's because PER is the "schema-based" version of ASN.1 while BER is sort of like the "schema-free" version of ASN.1 encodings. Note: The ASN.1 community went through much the same progression that some people hope the "XML" community will go through. i.e. BER was self-describing and could actually be parsed without schema knowledge. But, it was inefficient and fat (but smaller than XML in most cases). PER was able to get compactness and efficiency by forcing the parser to understand the schema. You choose which to use based on your need. The schema-free vs schema-required arguments raged many years ago in the ASN.1 community. What it basically comes down to is that which is right depends on the application. If you've got a great deal of variety in what you're receiving and the format definition frequently changes, then use something like BER. But, if you've stablized your format and it doesn't change more frequently than you're able to deploy a new schema, then PER is great. In summary: There is no need to "shoe-horn" self-description into ASN.1. It has been there since day one. i.e. almost 20 years now... bob wyman 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
