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 Bina

[ Lists Home | Date Index | Thread Index ]

John Larmouth wrote:

> Simplifying some encoding rules is certainly possible - BER does not 
> really need both definite and indefinite length encodings, but there 
> were (and probably still are) groups that would fight to the death for 
> one or the other.

I'd argue for both being useful. Encoder's option.

Basically, definite length means that you know the length of the entire 
string before you start writing it, while indefinite lets you keep 
outputting it in chunks - which is useful if you're streaming data.

> (Definite length is great for small things, is abysmal if you have to 
> churn disk to find the length before you send it at the head.  
> Indefinite is usually an extra octet, and is only possible if the 
> contents are structured.  It would be hard to eliminate either in ASN.2.)

Indeed. Choice is good :-)

> "Simplifying" the notation could mean removing things such as 
> parameterisation - Yuck!  that is needed - or changing the syntax for 
> easier parsing (in ECN the start of a parameter list was introduced by 
> "{<" rather than by just "{" to make life easier for parsers.  I am not 
> sure that is really progress!  There are as many different and 
> conflicting proposals for "simplifying" ASN.1 as there are people 
> involved with it!

Indeed... alas, I'm too short on free time this year to have a stab at 
it myself :-(

I wouldn't take features out. All the features are there for a good 
reason. I'd just tidy up the syntax of the ASN itself, probably using a 
nice trick like LISP does with s-expressions (make a concise written 
value notation, define a type for type declarations, then type 
declarations are written in the concise value notation), and I'd like to 
have UTF8String replaced with BMPString, too, and the difference between 
the two in terms of encoding taken away! UTF8 is just a concrete 
representation of the BMP...

But these are pretty minor problems. Effort would be better spent on the 
lack of open source implementations than picking at the standards. They 
have stood the test of time and are the result of a lot of smart people 
working on them!

> John L



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

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