Re: [ASN.1] ASN.1 beginner questions nagging at my brain....
Steven I really appreciate the info. I've slowly thought about all you said and hopefully have some impressive questions regarding your prose if you don't mind... Q1: Why would XML Schema designers ever have been motivated to create it in the first place?? The only reason I can think of to have a more abstract representation like ASN.1 is to allow different encodings. But, if we assume XML Schema guys want XML to take over the world then this seems counterproductive. On the other hand, if they are open to other encodings, why not just use ASN.1 with XER when they want XML??? Q2: If I'm not mistaken XML is Unicode/ASCII based. If we call this an encoding language or transfer syntax then how come people have problems with little endian and big endian differences?? Endianness problems are a result of the bit details not being specified in full detail right?? Does this mean one flaw with XML and Unicode is that they don't rigorously specify enough details about the locations of ones and zeroes like BER, DER, PER, etc.?? Thanks again, Chris On Thu, Aug 14, 2003 at 02:11:25PM +1000, Steven Legg wrote: Hi Chris, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] The following basic questions are nagging at my brain Q1: XML is a universal standard data format that is gaining popularity fast. What is the role of ASN.1 in a world with XML?? Is it a competing standard?? Does it add any /more/ value? Q2: I read about ASN.1 specifying a binary format for data. I think this may be the (only?) extra contribution ASN.1 has that XML does not have. If so, why does ASN.1 also specify an ASCII format??? Perhaps it would have been more useful to /just/ make ASN.1 specify a standard way to encode XML in binary? Let me put things into the right context first. ASN.1 is a language for describing the structure of data in abstract terms. The A in ASN.1 stands for Abstract after all. By itself an ASN.1 specification does not specify the concrete representation of the data in transmission or storage. The concrete representation is known as the transfer syntax in ASN.1 terms and is determined by the application of one of a set of encoding rules. Each set of rules has different properties with respect to space efficiency, time efficiency and readability (among other things) of the resulting transfer syntax. XML is essentially analogous to a transfer syntax. There are encoding rules for ASN.1 (e.g. XER and DXER) which format data as XML. XML is not in competition with ASN.1. Comparing XML to ASN.1 is like comparing concrete to architects' drawings. Rather, ASN.1 is analogous to, and in competition with, XML Schema, RELAX NG and DTDs. An obvious advantage of ASN.1 is that the same data (semantically) can be formatted in other ways (syntactically) by applying different encoding rules. For example, a very compact binary representation results from using PER. Currently the only transfer syntax for XML Schema or RELAX NG is XML. With respect to XML formatted data, ASN.1, XML Schema and RELAX NG are broadly similar in what they express although they differ in the details. Each of these languages has some features which have no equivalent in the other languages. For example, ASN.1 has a much richer repertoire for defining restricted types (constrained types) than the other languages. There is work in progress by the ITU-T and ISO to extend ASN.1 so that it has at least the expressibility of XML Schema. A notable feature of XML Schema and RELAX NG is that the syntax of the schema languages they define is also XML, whereas the syntax of ASN.1 specifications is unique. It does not correspond to a transfer syntax generated by any of the encoding rules. However there is an IETF draft of a specification for representing ASN.1 specifications in XML syntax called ASN.1 Schema. That specification brings to ASN.1 all the advantages attributed to XML Schema and RELAX NG in having an XML syntax. I note that RELAX NG specifications now have an non-XML compact representation. RELAX NG has followed the reverse path to ASN.1! To refine the analogies, an ASN.1 specification is analogous to the compact syntax for RELAX NG (there is no equivalent for XML Schema as far as I know) and an ASN.1 Schema document is analogous to an XML Schema document or RELAX NG grammar document. XML is just a transfer syntax. For most new XML-based applications it won't make much difference whether they are specified in ASN.1/ASN.1 Schema, XML Schema or RELAX NG. All three schema languages can do the job. Some applications will have particular requirements that can be best met by only one of these languages, which will make that language the best choice, though often the choice of schema language will come down to the application designers' prejudices and what they are
RE: [ASN.1] ASN.1 beginner questions nagging at my brain....
Hi Chris, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] The following basic questions are nagging at my brain Q1: XML is a universal standard data format that is gaining popularity fast. What is the role of ASN.1 in a world with XML?? Is it a competing standard?? Does it add any /more/ value? Q2: I read about ASN.1 specifying a binary format for data. I think this may be the (only?) extra contribution ASN.1 has that XML does not have. If so, why does ASN.1 also specify an ASCII format??? Perhaps it would have been more useful to /just/ make ASN.1 specify a standard way to encode XML in binary? Let me put things into the right context first. ASN.1 is a language for describing the structure of data in abstract terms. The A in ASN.1 stands for Abstract after all. By itself an ASN.1 specification does not specify the concrete representation of the data in transmission or storage. The concrete representation is known as the transfer syntax in ASN.1 terms and is determined by the application of one of a set of encoding rules. Each set of rules has different properties with respect to space efficiency, time efficiency and readability (among other things) of the resulting transfer syntax. XML is essentially analogous to a transfer syntax. There are encoding rules for ASN.1 (e.g. XER and DXER) which format data as XML. XML is not in competition with ASN.1. Comparing XML to ASN.1 is like comparing concrete to architects' drawings. Rather, ASN.1 is analogous to, and in competition with, XML Schema, RELAX NG and DTDs. An obvious advantage of ASN.1 is that the same data (semantically) can be formatted in other ways (syntactically) by applying different encoding rules. For example, a very compact binary representation results from using PER. Currently the only transfer syntax for XML Schema or RELAX NG is XML. With respect to XML formatted data, ASN.1, XML Schema and RELAX NG are broadly similar in what they express although they differ in the details. Each of these languages has some features which have no equivalent in the other languages. For example, ASN.1 has a much richer repertoire for defining restricted types (constrained types) than the other languages. There is work in progress by the ITU-T and ISO to extend ASN.1 so that it has at least the expressibility of XML Schema. A notable feature of XML Schema and RELAX NG is that the syntax of the schema languages they define is also XML, whereas the syntax of ASN.1 specifications is unique. It does not correspond to a transfer syntax generated by any of the encoding rules. However there is an IETF draft of a specification for representing ASN.1 specifications in XML syntax called ASN.1 Schema. That specification brings to ASN.1 all the advantages attributed to XML Schema and RELAX NG in having an XML syntax. I note that RELAX NG specifications now have an non-XML compact representation. RELAX NG has followed the reverse path to ASN.1! To refine the analogies, an ASN.1 specification is analogous to the compact syntax for RELAX NG (there is no equivalent for XML Schema as far as I know) and an ASN.1 Schema document is analogous to an XML Schema document or RELAX NG grammar document. XML is just a transfer syntax. For most new XML-based applications it won't make much difference whether they are specified in ASN.1/ASN.1 Schema, XML Schema or RELAX NG. All three schema languages can do the job. Some applications will have particular requirements that can be best met by only one of these languages, which will make that language the best choice, though often the choice of schema language will come down to the application designers' prejudices and what they are familiar with. What makes ASN.1 important in the crowd is the body of prior art. There are numerous examples of existing, widely deployed, mature applications defined in terms of ASN.1. It seems to me that there are too many people seeking to redefine these applications from scratch just so that they can use XML when it makes much more sense to regard ASN.1 as an XML schema language and just apply a different set of encoding rules to the existing application. Q3: Why do we /need/ a standard binary format?? The Transport Layer of the TCP/IP network stack has been happily moving tons of bits thru the Internet via sockets and port for years without any need for a standard way to represent ones and zeroes!!! Granted it is true that there is no standardization of *how* or *what* gets sent thru the Transport Layer. In the Application Layer, applications make up their own standard FTP, SSH, TELNET, HTTP each define their own protocol. I suppose we could start making applications all use ASN.1 instead of reinventing the wheel but why would that be useful? Q4: Many papers on ASN.1 define it's functionality in terms of two upper