From: Andrew Lentvorski <[EMAIL PROTECTED]>
Just for reference, my background is in the area of VLSI design where I
have been dealing with proprietary, buggy, piece of crap storage and
interchange formats for *decades*. Every vendor outputs a different
*broken* format; often it is the same as their internal format. Yes, they
often introduce bugs into their own data. Each one has a different set of
characters that they accept (tool A only takes uppercase ASCII; tool B
gives case meaning; tool C can accept punctuation but only allows
lowercase).
And XML wouldn't fix this. They'd end up with their own broken
DTDs/schemas. Making it XML doesn't magicly make them use the same form of
XML. Its to their advantage not to- lock in.
Real-world results are against you here ... ;)
I have yet to get see a grammar specification for any interchange format I
work with other than XML.
They have them, that doesn't mean they publish them. Just like it doesn't
mean they'd publish their XML schema/DTD.
The difference is that with XML, *I* can create the DTD or Schema to do
validation even if the original author doesn't. This allows me to trap
badly formed incoming data *before* it has a chance to enter my system.
You can create one for a non-XML grammar as well. Sure, you need to figure
out their grammar first, but you'd need to figure out their XML grammar as
well. Equivalent amount of work.
Here we disagree. The fact that I *can* activate the nasty stuff later on
is more than sufficient for me to incur the overhead.
Not if you run statistics on it. Taking large overhead on all cases so you
can enable it on a tiny minority doesn't work out in the end.
Gabe
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
