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 ]

Michael Champion wrote:
> This gets into another point -- there is a widely-held
belief by many  
> (most?) XML developers/analysts that XML *is* a text markup 
format, so  
> "XML objects" is an oxymoron.  See  
> http://lists.w3.org/Archives/Public/www-
> for the most recent outbreak of the long running debate on 
this point .

    I've read this discussion, started by Tim Bray, and I 
must say that just as Tim Bray has disagreed "profoundly" 
with some who dispute his contentions, I disagree profoundly 
with Bray's position. While much of the history he cites is 
accurate, his conclusions are questionable. He argues from 
the specific to the general and ascribes cause to what may be 
only anecdotal circumstance.
    Bray observes that Internet standards, many of which have 
been very successful, have relied almost exclusively on 
specifications of concrete rather than abstract syntax. He 
argues that there is a lesson to be learned here: That since 
past successes have been based on concrete syntax, future 
efforts should focus on concrete, not abstract, syntax. I 
believe he is wrong.
    The process of defining Internet standards has been very 
ad hoc. As someone decides they have a need, they start a new 
effort and put together a spec. These things are usually 
defined largely in isolation of each other (there is no 
real "Internet Architecture") and are typically done with a 
goal of economizing specification effort. Since the goal of 
such protocols is to permit interoperation, the specs 
inevitably are heavily focused on concrete syntax -- the 
minimum needed to ensure interoperability given the 
    Many developers of Internet protocols actually understand 
their services to have very precise and well thought out 
abstract models. However, a problem appears in translating 
those models to concrete syntax. The problem is that there 
are an essentially infinite number of ways to translate an 
abstract model into concrete syntax. What you see in an RFC 
or similar document is just one selection from the infinite 
range of options. 
    Because most protocols are defined in isolation of each 
other and because many implementation efforts are focused on 
a single protocol -- rather than a suite of protocols, what 
you end up with is a tower of Babel. Each protocol developer 
defines concrete syntax based on personal experience and 
preferences and nobody really minds too much since reuse 
between protocols is more a cost to a new protocol definer 
rather than something that reduces cost. Worse, each protocol 
usually uses a slightly different method for defining the 
concrete syntax -- thus, to understand a new protocol, you 
must also come to learn the syntax and conventions used to 
describe it.
    Well, the groups that defined ASN.1 had a different view 
of the world -- a view that has often been attacked as 
overbroad, nonetheless, it resulted in a different approach 
to the problems of protocol design and implementation.
    ASN.1 was defined as part of the ISO process and was 
explicitly intended to be used and reused in a broad range of 
protocols. It was expected that implementors would be 
required to work on a broad range of protocols and that work 
done on one protocol shouldn't be duplicated on another. 
Since the pecularities related to having massive numbers of 
divergent concrete syntaxes was already a problem back in the 
80's, ASN.1 was chosen as a mechanism to largely remove the 
concrete syntax problem from the domain of protocol design. 
Much of the complexity of ASN.1, when compared to an 
application specific protocol, thus results from this desire 
to optimize the broad realm of protocol design rather than 
some specific and short-term protocol development problem.
    ASN.1 provides completely unambiguous translations 
between concrete and abstract syntax and thus allows protocol 
developers to focus, as they should, on their abstract models 
rather than on the problem of how to express those models on 
the wire or on disk. A suite of deterministic encoders and 
decoders are provided, each optimized for one or another 
environment and each specified to the point where there is 
little risk of failure to interoperate between 
implementations. The result is that an "ASN.1 developer" 
hardly ever even thinks about concrete syntax -- because they 
don't need to. Concrete syntax is something that can be 
chosen by the implementor as a configuration option, either 
globally, or on an exchange by exchange basis. Concrete 
syntax is not an essential part of the protocol design 
process. One of the very nice side effects of this 
deterministic translation is that developers can move from 
one protocol to another and find that they aren't suprised by 
or required to learn protocol-specific concrete syntaxes. 
Once you learn ASN.1 and a bit about the encoder/decoders, 
you don't need to learn anything new in order to understand a 
new protocol. You could have a hundred protocols, each 
designed by a different person, yet each would encode a 
sequence or integer in exactly the same way...
    Tim Bray's conclusion's might be valid if an alternative 
didn't exist. As long as protocols are being specified in 
isolation and reuse between protocols isn't valued, as long 
as there is no way to translate deterministically from 
abstract to concrete, then we're stuck having to concentrate 
on the concrete syntax. But,... there is another way -- the 
ASN.1 way. Agree on deterministic conversions from abstract 
to concrete and remove most concerns about concrete encoding 
from the design equation.
    It should be noted that even though ASN.1 allows one to 
define protocols abstractly, this doesn't mean that 
implementors can't focus on the concrete syntax. There are, 
for instance, many "quick and dirty" or simple 
implementations of services originally defined in ASN.1 where 
the developers haven't made use of reusable encoder/decoders 
or ASN.1 compilers. What they've done is simply written code 
that mimics what these tools would have generated. The point 
is that with a system like ASN.1 you get the choice. You can 
implement at the concrete level and use the ASN.1 definitions 
in concert with an understanding of encoding rules to tell 
you what code to write. Or, you can use a tool that does the 
work for you. (Personally, I prefer letting tools do work for 
     I'm sure this too-long note won't put an end to the 
concrete vs abstract debate that Tim Bray has reopened... 
Such issues are so much fun to debate that people won't let 
them go away.

    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