Re: ASN.1 and XML

["Al B. Snell" <alaric@alaric-snell.com>]

On Thu, 24 May 2001, Christian Nentwich wrote:

> > One big win of ASN.1 over XML is that, from the same "schema", you can use
> > different encoding rules. When debugging/testing, or other situations
> 
> I only know the basics of ASN.1, but I wouldn't see the above as a big win.
> XML always looks the same. Good. You know what you're getting, no need to
> find out what you're looking at, no need to worry that someone will send you
> the
> same data in a different encoding.

Well, if when agreeing the data transfer you said "Thou shalt upload a
BER-encoded message of this ASN.1 type by FTP (username foo, password
bar) to "ftp.thingy.net" in the directory "/incoming/", then you can slap
'em if they do that. Them changing encoding is less of a worry than them
screwing up the FTP login details, or changing the IP they connect from so
your firewall breaks it, or them failing to upload the data at all...

Believe me. I've done a lot of work with data transfer between different
companies. And the kinds of issues that XML claims to solve are the least
of our worries. Some of them can't get a CSV file right (they randomly
change date formats) - although a schema validator would pick that up
earlier than our date parsing function does,it'd still be broken until we
fixed the date parsing function (and at least we don't have to try and
update a regexp in a schema to allow for their new date format every time
they change it :-). If they can't get a CSV correct (random change of
delimiters!), their chances of producing well formed XML aren't that
great :-)

> 
> Christian Nentwich
> 

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software