OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] ASN.1 is an XML Schema Language (Fix those lists!) and Bin

[ Lists Home | Date Index | Thread Index ]

Tim Bray wrote:
> [Internet is] an existence proof that syntax is *a* good 
> basis for interoperation.
	A focus on concrete syntax may have been good enough to get us
to where we are, but that doesn't mean it is the best approach or even
the only good approach.

> I think it is actually a win, in networked environments, 
> to decouple the sender's and receiver's data models. 
	Sure, but we shouldn't decouple the implementor's
understanding of the abstract data model from the protocol designer's
understanding of it. The ASN.1 approach of designing with abstract
syntax and then using deterministic translations to concrete syntax
greatly improves the effectiveness with which a protocol can be
communicated. The result should be higher interoperability.

> the notion that there's no re-use between protocols in the 
> Web/concrete approach is just silly; HTTP is
	As I'm sure you realize, I was refering to things like Telnet,
FTP, SMTP, SNMP, NNTP, etc. which have completely divergent code bases
above the TCP/IP layer. The history of protocol development is made up
of these isolated efforts and it was this history that your original
mailing seemed to be refering to. Reuse of protocol components on the
Internet has been a rare and primarily recent phenomenon. (With some
exceptions -- notably OSI efforts in ancient history and some recent
examples in the Web world.)

> it is a defining characteristic of Web Architecture that 
> interactions are defined at the level of syntax, and for 
> the needs of the Web, this works well and should be respected.
	Are you saying that just because it has worked in the past we
shouldn't try to do better? In any case, an argument for ASN.1 is not
an argument against concrete syntax. Remember, the concrete syntax for
something defined in ASN.1 is deterministically generated. That means
that you can view ASN.1 as simply a complex form of BNF. You *do not*
lose the benefits of agreement on concrete syntax by moving to
specification via abstract syntax as long as you keep deterministic
generation of concrete syntax. What you lose is the opportunity to
introduce anecdotal variances between concrete syntaxes and thus the
opportunity to build lots of new parsers... Using the ASN.1 way, you
only write one parser for each encoding format (BER,PER, XML, etc.)
and that parser will serve either one or thousands of distinct uses...
This is a good thing.

		bob wyman


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS