YAML > XML

Discuss.


Yet Another Markup Language (YAML) was a great markup language. A way to handle scalars, array, hashes and multi-lines in a human-readable form, and move to and from data structures easily, theoretically in many languages (I have no experienced in this regard).

The best comment I ever heard was "It's great, we just spit out our nightly processing run reports in YAML and the bosses secretary can read them just fine".

Except that somewhere along the way, it would seem the dream was lost. Instead of a straight forward documents<--->struct language, we are seemingly now left with a multi-doc-per-file data serialization language with all sorts of nasty holes in it.

In attempting to become all things to all people, it has become a failure at all of them (except possibly as a debugging data dumper).

It fails as a simple markup language, as it now supports structures and notations that humans have trouble understanding, especially non-technical humans.

It fails as a data serialization language. You simply can't serialize all the oddities of Perl data structures, such as circulars and objects and overloads and so on, without extensive work, and the assistance of those classes.

Storable does these tricky bits right, but it's taken years. Adding support for Singletons to Storable alone took several months, involved 4 people, and produced what is probably the largest rt.cpan.org comment trail of all time (Bug #4901)

YAML just blindly blesses things into classes, regardless of whether the class can support that, is loaded, or even exists.

Support for complex Perl structures also pretty much kills comprehensive cross-language support. The largest gripe that the Python people have with the JavaScript Archive Network is it's use of YAML.

You cannot implement Perl-complixity serialization without class hooks, and you can't sanely implement class hooks in any sort of cross-language fashion.

Noting the 4 outstanding bugs rated "Critical", 12 rated "Important", and about 15 other smaller ones, and as much as it pains me to do this, I have to rate YAML as a failure.

And given the mission it has now set itself, I cannot see it ever being able to succeed. There are too many irresolvable paradoxs.

I'd greatly like to see something that addressed the original goal... perhaps "YIML - YIML isa Markup Language"?
from http://cpanratings.perl.org/dist/YAML

Thread over.

>>2
I like the forced indentation though.

JSON <=> XML > YAML

>>4
What the fuck are you talking about, JSON >>> <languagedescription type="tags" title="lots of shitty tags"><title><forfuckingreal o:id="42B56C">XML</forfuckingreal></title></languagedescription>

>>5
Simple XML can actually be a decent, lightweight file format for a lot of purposes. HTML, for example.
Almost everything wrong with it can be traced back to Java developers, who unfortunately have taken a liking to writing their ad hoc, informally-specified, bug-ridden, slow implementations of half of Common Lisp in it. SOAP and ilk are wrong on so many levels. But Java and its fold can make anything look bad.
If you strip out the crud (namespaces and doctypes and whatnot),
you have a simple way to represent generic hierarchical content.

Now for internal passing of simple structured data, like Javascript - Server communication, JSON is miles ahead, but I won't be using it for a document format anytime soon.

>>6
Tags are stupid, even in simple HTML. Compare <fuck>lol</fuck> to other possible formats, such as fuck: 'lol', (fuck lol), fuck{lol}, fuck=lol, etc. Agree on SOAP and Java.

Also, JSON is directly executable by JavaScript and Python, which should be considered a major advantage.

>>7
SGML did it right, and nobody paid any attention.
<fuck/lol/

>>7
Of those alternatives, I'd consider most inferior to XML, as they don't even nest! S-expressions are... okay, I suppose, but they do not clearly separate the tags from the content, and malformed content like mismatched parenthesis can fuck up the parser with no clear indication where the fuckup started.
It's a wash, really, but XML won and is now pretty much the standard.

Being directly executable by JavaScript and Python means shit if you're not programming in either, or if you do not trust the content.

>>8
Still stupid. Why repeating the name of the crap you're closing? (Before you say it, it's not like it's any clearer if you can recursively include tags of the same name.)

Of those alternatives, I'd consider most inferior to XML, as they don't even nest!
Java fag
{fuck: {java: 'fag'}}
(fuck (java fag))
fuck{java{fag}}

[really/really/fuck]
java=fag

>>9
S-expressions are... okay, I suppose, but they do not clearly separate the tags from the content
Tags are, in a way, content. They are of type symbol. If you want, you can use symbols for what you call tags, and strings (stuff in "") for what you call content. For example:
(people (java-fag (name ">>9")) (traitor (name "Guy Steele")))

malformed content like mismatched parenthesis can fuck up the parser
lern2cod
It's MUCH simpler to write an S-expression parser.

with no clear indication where the fuckup started.
What's the difference between...
(lol (lol (lol )))))) ;oops
and
<lol><lol><lol> </lol></lol></lol></lol></lol></lol> <!-- oops -->
Besides the ugly fuck piece of a shit of a syntax and possible waste of Internet bandwidth in the second case?

XML won and is now pretty much the standard.
The standard of what? XML is just today's enterprise best-practice object-oriented business synergy solution.

Being directly executable by JavaScript and Python means shit if you're not programming in either
Python is a good language for web applications development, and JavaScript is present in most web browsers (even elinks), so at least for the web, it's relevant to my interests.

or if you do not trust the content.
You can safely eval in the client side, not much harm to do with JavaScript and he's the luser anyways. As for Python, yeah, you better parse it yourself (even eval(input, {}, {}) is vulnerable to crap like __import__('os').system('echo lol>hax')), but for quick nigger scripting jobs where you trust the input (like a config file), you can afford to eval.

>>9

There is no difference between tags and content, which is one of the main reasons XML fails hard.

<tag content="blah"/> vs <tag>blah</tag>

>>11

So, which one is bettter?

I propose THE FORCED INDENTATION OF CONTENT:


HTML:
  BODY:
    H1:
      The Forced Indentation of Content
    by (I: Guido van Rossum)
    P:
      The advantages of the forced indentation of content over XML are\:
      UL STYLE='margin-left: 4em':
        (LI: Faggots will properly indent their markup)
        (LI: No longer need to close tags)
        (LI: No indentation style wars)
        (LI: More Pythonic)
    P:
      Of course, we also support (U: (I: expression) tags) which
      have to be wrapped in parens \(and we don't have that
      entity faggotry; we escape with backslash\).

>>13
I wrote that as a joke/troll, and the more I look at it, the more I like it. I still prefer S-expressions, but the forced indentation of content is much better than that XML bullshit.

>>13

How about preformatted content?

>>10
The standard of having library support in just about every language out there.
Yes, XML does looks a bit verbose for the toy examples you provide, and the error detection falls a bit short when you just nest identical tags. It should be used for storing documents and hierarchical data, especially if it should be portable amongst applications.

Python is relevant to my interests too, and as I said, I wouldn't use XML for just communicating with client Javascript.

>>13,14
Sure, that looks halfway decent, except for maybe the STYLE= thing. Significant whitespace doesn't play very well with PHP style templates though.

Are S-expressions actually used for much outside of the Lisp world? I have the distinct impression that they aren't.

Are S-expressions actually used for much outside of the Lisp world?
they're not even used for much inside the lisp world.

>>15
Should work like this

PRE:
  a #New forced indentation offset set by this line
  b #Will show below a
   c #This is not a new block because PRE is speshul
  d #Shows below b
 e #Syntax error: the forced indentation of content has been violated

>>16
The standard of having library support in just about every language out there.
Parsing JSON is so simple it's easier to write your own JSON parser (let alone an S-expression parser, a kid's homework) for a language that doesn't come with one, than to using an existing XML parser.

Yes, XML does looks a bit verbose for the toy examples you provide
And for more complex examples it's more complexly verbose. It's not like it'll become more efficient with more tags and documents, you keep repeating every fucking tag when closing it and wasting angle brackets.

especially if it should be portable amongst applications
And what makes XML portable and JSON or S-expressions not?

Sure, that looks halfway decent, except for maybe the STYLE= thing.
I feel the same way; I should have thought of something better for that.

Are S-expressions actually used for much outside of the Lisp world?
When you least expect it: http://www.oracle-base.com/articles/misc/OracleNetworkConfiguration.php
(Not perfect Lisp fashion, but awfully close.)

Actually, I haven't seen them much outside Lisp (yet there are like two dozen active Lisp dialects including embedded languages), but I haven't seen any other format aside from INI get universal either before businessmen and retards started to circle-jerk to their newly-found enterprise bussiness solution XML.

>>15
Or perhaps we can use '''quotes''', lol

>>18

But pre shouldn't require `special' syntax (it doesn't in HTML). It can be applied anywhere by setting white-space: pre as style.

I haven't seen any other format aside from INI get universal either before businessmen and retards started to circle-jerk to their newly-found enterprise bussiness solution XML.

csv?
but yes. They're all "XML XML XML". it's just a fucking format. It's not that big of a deal.

malformed content like mismatched parenthesis can fuck up the parser
it's not really hard to see where it failed, methinks. Just autoindent, and identation should give you the clue about where everything started.

>>12

So, which one is bettter?

Neither.  Both are FAIL, by way of superfluousnessicity and being XML.

>>21
The big deal is exactly that 'everybody' is using it, instead of making up their own binary formats, or trying to contort INI files into containing nested data structures. Thus, if you are familiar with a XML parser, you can just look at the format documentation and hack up a reader in no time.
Without the circle-jerk it would be just yet another slightly ugly markup language.

>>21
Big consulting companies as well as magazines and web loggers somehow convinced idiot businessmen that as soon as something uses XML, it can magically talk to anything else using XML.

Just autoindent, and identation should give you the clue about where everything started.
Then shall we have the forced indentation of content?

>>24
Nice ID

>>24
no, not forced. With s-expressions (with XML too, btw), you can format a document to have it auto indented. indentation it's not significant.