[9fans] asn.1 alternatives

[Charles Forsyth <forsyth@terzarima.net>]

>> > What are the alternatives?  My pick is ASN.1, any time.  You can call
>> > the ITU-T by as many ugly names as you like, but their standards are
>> > considerably more firm than more recent publications.

when i need to represent more than simple text or values, or attribute value pairs, which isn't all that often,
more and more i use Rivest S-expressions, as i did on wednesday.
they are unambiguous (unlike both ASN.1 and XML),
easy to read and write, that can represent binary directly where that's appropriate,
with an `advanced textual form' (like it!) that people can read without suffering eye strain,
but with a well-defined canonical form (always helpful when comparing or signing things).

i keep intending to try armstrong's ubf, but haven't, yet.
it's perhaps more in the XML-RPC or ASN.1 realm.
it has some good ideas, anyhow.

simple text or values, or attribute value pairs are often adequate,
require little code to read or write, and are often more efficient when all
costs are taken into account.   if you're lacking a `standard' for something
you'd like to use, and you need that extra justification,
just write an RFC, and then say ``i'm following an existing RFC''.

on the other hand, if you're trying to talk certain existing protocols, you need some
quantity of ASN.1; if you're trying to interpret certain existing data, you might need some XML.
just remember, though, that no one needs `Web Services', the os/360 for
the 21st century, and the upas tree of distributed systems.
whenever it comes up, just hack round it, and even that is more than it deserves.

also, in my experience, managers (pointy-head or not) are rarely overly
caught up by the technical details.  they just want such-and-such a problem to go away.
they usually don't really care how you do it, especially if it works well
and they never ever have to cut short a trip to the golf course because of it.