begin quoting Gabriel Sechan as of Tue, Oct 25, 2005 at 09:52:48PM -0500:
> >From: Andrew Lentvorski <[EMAIL PROTECTED]>
> >And we've had s-expressions for longer than that. So why are there so
> >many programs that *still* can't cope with any of following
> >"[EMAIL PROTECTED]&*()_+-={}[],.<>" in data?
>
> Generally, thats a command line issue, nothing more or less. And XML
> doesn't have anything to do with that problem.
Failing to provide an escape mechanism is a common problem for those
who design a one-off language the first time. I figure, if you can't
design a decent language, why should I hope that you might be able to
design a decent schema?
Most of the time that I end up having to deal with XML, it's from
someone who is using it for lists, bags, dictionaries, and key-values.
This is not obvious from looking at the XML, however. . .
[snip]
> >Or, better yet, the number of programs that still have hard-coded string
> >and buffer lengths. Oops. Stack smash.
>
> Bigger problem. But still nothing to do with XML.
I find it amazing that XML can be touted as a solution to buffer overflows.
[First written as "bugger overflows". How the mind wanders...]
> >Actually, you missed something more fundamental. It forces programmers to
> >deal with "parsed tokens". That's a *big* step up for most programmers
> >who normally just "throw a couple regexps down".
>
> Except that it doesn't. It only forces you to do so if you use an XML
> parser that generates tokens. Not all do.
I just got done with a project where I used the joys of XPath to pull
data out of XML files. It wasn't that much different than 'throwing a
couple of regexps down'. And about as fragile.
[snip]
> SUre we did. How else did anything get written before XML?
I've always been a fan of line-oriented files. Easy to parse -- you
don't even need lex and yacc or such tools. This probably wouldn't
work well with VLSI data, but a suprising amount of data can be
handled this way.
[snip]
> I can read binary or non-XML text quite well. Just give me the format.
I still want the format even if you give me XML. Just because the
tags are words doesn't mean I know what the MEAN. Especially when
they reduce all the tag-words down to two and three letter abbreviations
and acronyms.
[snip]
> Nope. Not unless you misdesign it. Anything as big as XML will, but XML
> is stupidly big. Thats why the idea of a meta-format for creating formats
> is not a good one.
It's like building a framework to solve a problem. You end up with a
lot of code, but now you have *two* problems...
[snip]
> Apparently you've never seen code to talk to telnet servers, or ftp.
> Writing a client for one of those requires more special cases and
> workarounds for specific servers than you can shake a stick at. Yet
> somehow, it all works.
I wrote a minimal FTP client once. It's a useful exercise. Very
educational. I've contemplated going back and rewriting it (I've
long since lost the source, I fear), and then implementing the server.
Of course, HTTP servers are even easier to write -- of course, if we
were to design and implement HTTP today, we wouldn't have GET and POST,
we'd have. . .
<get>
<url>
<protocol>http</protocol>
<machine>
<hostname>kernel-panic</hostname>
<domain>org</domain>
</machine>
<document>
wiki
</document>
</url>
<arguments>
<argument>
<key>user</key>
<key>stremler</key>
</argument>
<argument>
<key>location</key>
<key>homepage</key>
</argument>
</arguments>
<get>
Okay, yes, that's a bit excessive. It would probably end up having
to have an Envelope part, however.
[snip]
> >And my solution eventually evolves to be just as complex as as XML. I'd
> >rather start at the debugged endpoint, thanks.
>
> Except that it wouldn't. XML is as crufty as it is because it does
> everything. It incorporates unicode, it has 15 cadgillion ways to
> validate, it slices, it dices, and yes it even makes Julianne fries. If
...and it falls over and explodes if you plug it in to an ungrounded
outlet...
> you were looking to replace XML with another meta-standard, yes it would
> be about as complex. If you were looking to make just whats needed, it
> wouldn't be 1/10th as bad.
The KISS principle just isn't popular anymore.
-Stewart
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
