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 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 layers of the *OSI* network model. Why is this > > useful since the whole world uses the TCP/IP network model > > instead? > > Historically ASN.1 grew out of work on the OSI model. That's why some > papers still link ASN.1 to OSI, though ASN.1 stands on its own. > It does not depend on OSI. There are applications, like LDAP, that > are defined in ASN.1 but used exclusively with TCP/IP. Various people, > myself included, are now working on moving ASN.1 even further from > its roots to position it as an XML schema language as good as, and > in various ways better than, the other offerings. > > Regards, > Steven > > > > > Thanks in advance. > > > > Chris Seberino > > > > -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: [EMAIL PROTECTED] _______________________________________
