
Not the comp.text.sgml FAQ (2002) - Tomte
http://www.flightlab.com/~joe/sgml/faq-not.txt
======
pwinnski

      Q.  I'm designing my first DTD.  Should I use elements or
          attributes to store data?
    
      A.  Of course.  What else would you use?
    

I giggled.

~~~
tannhaeuser
If you find yourself torturing your head about whether to use elements or
attributes, then you're attempting to use a markup language as a general-
purpose data representation format, something it wasn't designed for.

SGML and XML are for _text_ , optionally marked up with tags/elements.
Attributes are for data about element presentation, and not intended to be
displayed directly. It's as simple as that.

~~~
vbezhenar
99% of XML applications are not for text. Take SVG as an example.

~~~
DaiPlusPlus
SVG was a mistake, but we're stuck with it.

Does SVG offer any advantages over, say, EMF/WMF? I know a strong advantage of
WMF is that the file format translates 1:1 into GDI calls, which makes it very
fast - but I don't see EMF files rendered with anti-aliasing or complex
gradients. What about PDF or PostScript?

~~~
vesinisa
SVG would actually be great if it wasn't such a feature creep. Filters, masks,
scripts and animations are supported only by some renderers, often
inconsistenly. This does not seem to stop SVG generators producing documents
using these features, often unnecessarily.

Good SVG can even be human-readable and -editable. I've actually fixed simple
broken SVGs with vim and a pocket calculator.

PostScript is great but as a binary format not very modern, where text-based
formats seem preferred. I had to look up WMF and dumping calls to Microsoft
API as an 'open' standards does not sound too exciting, either.

~~~
fanf2
Postscript is a text format :-)

Its disadvantage is that it is a full on programming language, not
declarative, so it isn't friendly to editing tools.

~~~
vesinisa
You are right on both counts! I seem to have mixed it with PDF.

Sadly, programming is coming to SVG as well with more and more renderers
supporting JavaScript. Which might be great for some use cases, but again even
further disperses the field of possible generator/feature/renderer
combinations that might (will) fail.

------
weinzierl
In a similar vein there is _" XML Sucks"_ [1] and _" S-exp vs XML"_ [2]. Both
have been discussed here on HN in the past.

The first one claims (without giving a source) that James Clark once said or
wrote:

“Any damn fool could produce a better data format than XML” – James Clark
2007-04-06

[1]
[http://harmful.cat-v.org/software/xml/](http://harmful.cat-v.org/software/xml/)

[2]
[http://harmful.cat-v.org/software/xml/s-exp_vs_XML](http://harmful.cat-v.org/software/xml/s-exp_vs_XML)

~~~
xelxebar
I'm genuinely perplexed at that animosity towards XML. In that second link I'm
unable to find any substantive problem other than that "XML endtags make it
too verbose". That seems like a legitimate thing to worry about when
considering serialization formats, but where is all the vitriol coming from?

Bizzare.

~~~
marcoperaza
Beyond basic usage, XML is pretty complex: schemas, namespaces, XSLT, XSD,
DTD, XPath and XQuery.

There are plenty of good arguments for the XML way of doing things. For
example, having a rigorously defined way (XSLT) to specify transformations of
schema-conforming XML is more robust than ad-hoc code that wrangles schemaless
JSON.

But it does go against the hacker ethos and stands in the way of rapid
development. And wherever it is used, complexity and verbosity seem to often
follow. Look at SOAP, for example.

~~~
hyperpallium
Yes. As a tree structure, basic xml is fine. There are lots of other ways to
do it, but there's really not much difference. For communication, agreement on
a common language is more important than its intrinsic merits. (and xml partly
attained that because it looks like html, which was still new at the time).

But the xml ecosystem is horrible. Sensible ideas, horrific execution; like
namespaces and schema. Probably the single worst problem was using xml syntax
itself: it's like, a programming language that uses JSON for its syntax.

But also, there's guilt-by-association, people hate the enterprise culture
that uses xml - similar happened to java.

Though xpath is not so bad, and many people seem to quite like it.

Finally... json is a better match for data, basically by being c-like.
However, an ecosystem tumour is also growing, around JSON. Some even use json
syntax itself...

I wonder, if perhaps, a root issue is that the world is complex, and youthful
simplicity is corrupted as it adapts to cope with the real world... There is
hope, however; tools like `jq` never existed for xml.

~~~
jandrese
JSON and XML aren't really equivalent though. XML is a markup language, JSON
is a data serialization format. Of course a lot of hate for XML comes from
people trying to use it to serialize data, which it can do but only in a
clunky way. JSON is just plain better suited for what most people need.

~~~
hyperpallium

      s/serialization format/object notation/

