[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ASN.1 and XML
- From: "Al B. Snell" <alaric@alaric-snell.com>
- To: Frank Richards <frichards@softquad.com>
- Date: Thu, 24 May 2001 21:47:58 +0100 (BST)
On Thu, 24 May 2001, Frank Richards wrote:
> Once again, you're treading in places I've been. When they call me 'cause it
> ain't workin',
> I can count pointy brackets on my fingers and see the problem. I have to
> mung the CSV with a
> computer to figure it out.
The kind of issues we found didn't need hand checking to locate - when the
standard CSV parser, a Perl script with a loop containing a "my
($foo,$bar,$baz) = split(/,/,$_)" or whatever (can't remember much Perl
:-) gets the wrong number of columns (or the wrong delimiter so it's all
one column...) it's pretty clear what's wrong.
When we used regexps to pull apart dates, we went to the effort of putting
"or die 'Invalid date format ($foo)'" on the end of the line, so it points
it out to us.
Getting meaningful errors is just the odd "or die" here or there in the
code; it doesn't need a schema or DTD validator. It would be nice to use a
formal specification for the data interchange at the contract stage, as
opposed to driving a validator, but the way they keep drifting away from
the contractually agreed specification when it was in English along the
lines of "One line per record (lines terminated with ASCII newline
characters), with fields seperated by commas according to (insert table of
field meanings and formats here), like (insert a few examples here)", I
think it would have been little better :-)
>
> Frank
>
AS
--
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