Unsurprisingly, he says it much more eloquently than I ever managed. Until 
he starts relating people who use XML to people who voted for Bush, at 
least. :-) The first half is good, at least. :-)

http://harmful.cat-v.org/software/xml/s-exp_vs_XML

-- 
   Darren New, San Diego CA, USA (PST)
   Insanity is a small city on the western
   border of the State of Mind.

Post a reply to this message

> Unsurprisingly, he says it much more eloquently than I ever managed. Until 
> he starts relating people who use XML to people who voted for Bush, at 
> least. :-) The first half is good, at least. :-)
>
> http://harmful.cat-v.org/software/xml/s-exp_vs_XML

Wow, that guy is an idiot. S-exps are uglier than XML,
and XML is perty ugly. Besides, it's like trying to
compare apples and oranges. They're just different.

Still it's from 2002, I guess that has given him a few
years to get treatment.

Post a reply to this message

Tim Attwood <tim### [at] anti-spamcomcastnet> wrote:
> Wow, that guy is an idiot. S-exps are uglier than XML,
> and XML is perty ugly. Besides, it's like trying to
> compare apples and oranges. They're just different.

  I don't think that was his point.

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood wrote:
>> Unsurprisingly, he says it much more eloquently than I ever managed. 
>> Until he starts relating people who use XML to people who voted for 
>> Bush, at least. :-) The first half is good, at least. :-)
>>
>> http://harmful.cat-v.org/software/xml/s-exp_vs_XML
> 
> Wow, that guy is an idiot. S-exps are uglier than XML,

I didn't think S-exps was what he was after, other than in the name of the 
URL. He makes a good point that
<integer>0</integer>
is a dumb-ass way of encoding data. :-)

The parts I thought are good are
1) Don't use XML if you're not doing markup, i.e., if you don't have orders 
of magnitude more cdata than tag text
2) If you're going to define something that uses unicode, get rid of the 
crap that lets you also define escape sequences, because nobody is going to 
ever get that right anyway or want to use it.

The number of times I've seen XML misused and *therefore* broken in just 
this way is legion.

-- 
   Darren New, San Diego CA, USA (PST)
   Insanity is a small city on the western
   border of the State of Mind.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> He makes a good point that
> <integer>0</integer>
> is a dumb-ass way of encoding data. :-)

  I never understood why the closing tag must be named. What's the point?
It's only a complete waste of space and resources. If they at least had
made naming the closing tag *optional*, that would have been much better.
If a person writing XML by hand wants to name his closing tags, he can do
so, but programs generating XML could use nameless block-closing tags for
efficiency. A program reading such input will not get confused by nameless
closing tags, as long as it's a valid file.

  LaTeX has both named and nameless closing symbols for blocks. The nameless
ones work simply with a syntax like: \tagname{some data here}
  What would be wrong with that?

  I have always felt that XML is schizophrenic: It tries to be "human-
readable", but at the same time it's *really* intended only for programs
to read and generate. So it's trying to appeal to two completely different
targets, and the result is a bloated mess.

  And rather unnecessarily at that, IMO. If they had done it with similar
principles to LaTeX, it would have been human-readable, human-writable and
relatively compact, all at the same time. Sure, it would have made XML parsers
more complicated, but that's what programs are for: To ease the burden of
people.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   I never understood why the closing tag must be named. What's the point?

A tiny increase in the ability to handle or at least detect malformed XML.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Warp wrote:

> >   I never understood why the closing tag must be named. What's the point?

> A tiny increase in the ability to handle or at least detect malformed XML.

  Why should a program be able to try to guess what a malformed XML file
might be trying to say? There's no way of unambiguously tell what the
properly-formatted version would have looked like.

  And if the XML file is malformed, it means that a person wrote it by hand.
Wouldn't it be better to directly tell the person that there's a mistake in
the file, rather than try to hide it, and possibly interpret it wrongly?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> He makes a good point that
>> <integer>0</integer>
>> is a dumb-ass way of encoding data. :-)
> 
>   I never understood why the closing tag must be named. What's the point?

The point is to make it easy to check the data is formatted correctly.

In SGML, you could omit the closing tags when it wasn't ambiguous. If your 
DTD said paragraphs cannot nest inside paragraphs, you could write

<p> first paragraph <p> second paragraph <p> third paragraph <section> next

just like you could in the very first versions of HTML.

XML tried to "simplify" it, but of course they simplified it for the writer 
of the XML parser, rather than for the author of the XML data. SGML also 
required a DTD, while XML can be parsed without.

Of course, you could just have </> mean "close the most recent tag that 
hasn't been closed", and then you're really close to having s-expr's. ;-)

>   I have always felt that XML is schizophrenic: It tries to be "human-
> readable", but at the same time it's *really* intended only for programs
> to read and generate. So it's trying to appeal to two completely different
> targets, and the result is a bloated mess.

Yep.

I see a lot of arguments that it's unnecessary to have both attributes and 
nested CDATA. This argument, however, only comes from people who don't use 
XML for markup. CDATA is the prose in your document. Attributes aren't. It's 
pretty straightforward if you're using it for markup. If you're using it as 
a wrapper for SOAP, then it doesn't make sense to have both attributes and 
CDATA, but then it doesn't make sense to use XML to start with in that case.

>   And rather unnecessarily at that, IMO. If they had done it with similar
> principles to LaTeX, it would have been human-readable, human-writable and
> relatively compact, all at the same time. Sure, it would have made XML parsers
> more complicated, but that's what programs are for: To ease the burden of
> people.

Agreed. Or, if they wanted a data transfer language like for SOAP or 
whatever, use ASN.1. It's already standardized, easy to read, write, and 
verify, and has both human-readable and compact and time-efficient 
representations.

-- 
   Darren New, San Diego CA, USA (PST)
   Insanity is a small city on the western
   border of the State of Mind.

Post a reply to this message

>>   I never understood why the closing tag must be named. What's the point?
>
> A tiny increase in the ability to handle or at least detect malformed XML.

For example lets say you have a very large document, and you
typo and omit a closure. With a named closure you continue parsing
the document until you hit the next closure, and see that it doesn't
match, so you can exit early with an error. If you have unnamed
closures, then you continue parsing until the end of the file, (or the
top level tag), where you can then generate an error that says there
are more tags than closures, but then that error can't say for sure
which closure is missing, since unnamed closures are interchangable.

Personally I find flat tags clearer than forcing them into trees.

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> Warp wrote:
> 
>>>   I never understood why the closing tag must be named. What's the point?
> 
>> A tiny increase in the ability to handle or at least detect malformed XML.
> 
>   Why should a program be able to try to guess what a malformed XML file
> might be trying to say? There's no way of unambiguously tell what the
> properly-formatted version would have looked like.
> 
>   And if the XML file is malformed, it means that a person wrote it by hand.
> Wouldn't it be better to directly tell the person that there's a mistake in
> the file, rather than try to hide it, and possibly interpret it wrongly?
> 
Or.. It downloaded wrong (still does happen), got corrupted somehow, 
your application you wrote yourself isn't "writing" it out correctly, etc.

Would be different, I supposed, if they had made it like code, and the 
start tag was a "name", and everything else was between {}, or 
something, but..

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message