Slashdot Mirror

I propose we improve this by using human readable text files for feeds. Just straight old readable text.

Something like YAML, a more "human-readable" serialization intended to fill some of JSON's niche?

As long as its in YAML, I'll be fine. :)

I'm perplexed why people continue to use XML when there is YAML. What is it that makes XML so attractive as a durable format? it's not human readable in a practicale sense, and YAML very much is. Since it's delimeters are comlicated and variable, It's harder to parse in ad hoc ways than yaml (line and white space) which means that for rapidly extracting things there are no shorcuts to instantiating a whole document. It's hard to grep. And both formats can fully do the other ones job so they are interchangeable.

I would actually dispute all of your comments, but picking up on the last point in bold, one of XML's key features is "mixed content", which is apparently (according to http://yaml.org/xml.html) not possible in YAML.

To see how clean YAML is to reads for humans and to parse by machine look at a Sample Document. And here's something truly impressive, a Yaml Quick reference card written entirely in YAML itself. Not only is it a marvelously short card, it's human and machine readable. It's a superset of JSON too.

XML suffers from divergent purposes. Is XML supposed to be for markup, as implied by its name, or is it for data serialization? One of the worst parts of XML and HTML is the horrible redundancy required with closing tags. The only purpose of that redundancy was to make it easier for people to read, and it failed at that. Just adds clutter, same as adding "/* end if */" and "/* end loop */" comments to closing braces. Another bad idea was properties inside the tags. Needless complication.

YAML is way more readable, less bloated, and faster. JSON shares much with YAML. For what you're doing, I'd use YAML instead of XML.

But bad though XML is, the wistful hope that patents might kill XML is like hoping to escape cancer treatments by dying of a heart attack first. I'm pleased when any user of the patent system is hoist in their own petard, and hope they'll see the light. It would be best to cure the disease. Remove all basis for this trolling of others sweat and blood. It will be a huge step forward if Microsoft could figure out that everyone's interests, including their own, are better served if software could not be patented, and they began lobbying toward that end. I can't see MS ever joining such an effort. Instead, they hope the other guys have heart attacks, and even help them along a little, trying to manipulate their diets. Such a small minded approach to a big problem! Unworthy of a major business, but sadly, we see it all the time. Par for the course with the horrible leadership that infests our corporations.

We go back to stone tablets. Wow.

Yes. It is a truism, that modernity only very rarely, (if at all) produces truly superior technologies.

A similar realisation was made with XML not long ago, too.

I can hope that within my lifetime, the same truth will be rediscovered in mainstream terms, where the command line is concerned, as well.

I may be accused of suffering from an inverse form of the chronological snobbery fallacy. (the appeal to antiquity)

However, the reality is that, when used as a criteria for determining the quality of something, the appeal to antiquity far more commonly holds true than its' reversal. In most cases, there genuinely is no school like the old school.

1. Don't be fucking stupid.

I'm not.

XML needs replacing. I know you won't listen to me alone when I say that, however, but fortunately you don't have to. There's a replacement that you can read about here.

My own document format is a little less complex than YAML, but YAML is more thoroughly developed, and is intended to do more things.

2. It's XML. They can document it as well as they like; but said documentation is as long as I knew it was going to be. Anything written in XML is unavoidably difficult to read, by design. It isn't a format with which transparency is really possible.

3. If you're afraid of complex things, you really shouldn't be on the internet. I imagine you'd be happy living in a tent on the side of the mountain, but us societal folk like our technology.

This is garbage. The Internet's original application protocols are all (with the single exception of FTP) text-based.

I love technology, too. I just prefer it to be well designed. That means a couple of things.

a) That it's text based, and more purely text-based than XML. It doesn't need, at a fundamental level, to be anything other than text based, either. When I say that, I'm not saying that there shouldn't be support for multimedia; but protocols should be written in a purely textual way.

b) That it complies, broadly speaking, with what is written here.

Complexity also *is* a bad thing, yes. There was a time when computer programmers actually understood that. I'm not sure what's happened in the intervening few decades.

The waves are persistent, accessible to anyone who's added to them, and include the ability to track changes, so they ultimately work quite well as a medium for the non-tactical parts of an RPG.

IRC channels are entirely persistent. I regularly visit one that has existed for nearly 15 years now.

In terms of the ability to track changes, I'm assuming they mean something like CVS, but IRC can use date-stamped log files, as well.

IRC isn't less popular because it was a bad protocol. It's become somewhat less popular because corporations have marketed proprietary alternatives, and people have believed the claims about them supposedly being more capable, when in reality they aren't at all.

6. Another prejudice! Wooo! Some people would be ashamed to let the world know that they think that one, single word typed by one, single marketing droid determines the overall quality of the finished product... but not you! Fuck in-depth analysis! All you need is ONE WORD!

It might be a prejudice, but it's an accurate one. Go and find me a single case of the word, "richness," having been used, where the marketing droid in question actually bothers to define exactly what the word means. They never do. It's there purely to make what they're hyping sound good.

I really, really hope I was trolled, because knowing I wasted a bit of my time makes me feel MUCH better than knowing that someone as bitter and backwards as you is allowed to roam the internet.

I am in the ongoing process of attempting to learn to control my temper, and to avoid allowing quite so much bitterness to creep into what I write. Unfortunately, I didn't succeed in doing that in my last post. I'm hoping this one is a bit more clear.

And your own appeal to authority would work better if you had a little more respect for the most popular LISP dialect in the world. Seriously.

But consider two things: First, the storage is JSON (not JavaScript), and I don't actually know that it's the on-disk format (I doubt it), only that it's the format exposed to developers. What would you use in place of it, for a schema-free database? XML? ASN.1? Serialized objects in $my_favorite_language?

And for what it's worth, JSON is not just Javascript -- it's also valid notation (as in, you can pipe it through eval, if you really want to) for Python, Ruby 1.9, and probably others I don't know about.

The only better candidate I can think of is YAML, which is more complex to parse, and a superset of JSON anyway.

Second, the views (sort of a query language) aren't necessarily Javascript. It's true, Javascript is the default view format, but it can actually be any language that can operate on text sent via a Unix pipe. I hear Python developers are using it with some success.

But given the choice, would you rather write SQL than JavaScript? Really?

Of course, it also has the nice side effect that you can write an entire application in JavaScript, using AJAX, talking directly to the CouchDB server. But I'm guessing that's a side effect, not the real reason Javascript was chosen.

I'm late to the party, and there are certainly a ton of other good suggestions, but I just had to pipe in and cast another vote for YAML.

Even if you don't end up using it for this particular app, it definitely deserves a look. Although it'll never displace XML, it definitely answers at least some of the questions XML attempts to answer, reduces "tag bloat," and is easy on the eyes.

I'm looking at the YAML 1.1 specs and don't see anything about schemas or data validation. Am I overlooking something?

Yes you missed a couple things. As you may know XML has had multiple ways to define schema and multiple validators over the years. YAML has validation at several different levels. First in syntax, since there's no close tags one never has a missing close tag to deal with. Simple data types can be declared by !!tags. And More complex structures (i.e. classes) can be declared by the user with local !tags. And of course built in data structures like hashes, arrays and references/pointers are part of the syntax. IN all these cases the document description is really part of the document it self. that is the thing telling you that the next statement is an integer or string or float is in the document it self.

Since yaml has many built in URI (binary, hex, float, hash, ordered hash, array, etc...) plus it has extensible type tags for locally declared types (i.e. classes) that can validate their own attributes. There is not as much desire for a separate schema declaration or validator as there is with XML

However sometimes you still want a schema and validator. For higher order abstraction of the document's expected structure, one can use a different schema validator such as Kwalify which also works for JSON too. Finally, since one can place any XML document into a YAML document simply by indenting it one space--and no other changes at all--, you can always put XML document schema language into a YAML document and use that.

You don't have to do that with XML, either. You can, but you don't have to.

(Un)?fortunately, "the rest of us" seems to make up about 5% of the programming population. The rest of the rest of us are using XML.

I'm looking at the YAML 1.1 specs and don't see anything about schemas or data validation. Am I overlooking something?

You don't have to do that with XML, either. You can, but you don't have to.

(Un)?fortunately, "the rest of us" seems to make up about 5% of the programming population. The rest of the rest of us are using XML.

I think you answered the question. Yes. for many uses being able to use a simple text editor is great.

Have a look sometime at the yaml documetnation quick reference-card : it's written in YAML and fits on one page. That's how compact yet human readable it is, try that in XML.

These days everything is one library away from being immediately available for use. Since YAML can do everything XML can do, and because it's trivial to insert XML into YAML (but not the reverse), you really could replace XML with it. YAML even handles relational data, something XML has only begun to do.

JSON is lightweight, and yet it remains human readable and editable. XML lets you forget some of the security concerns of JSON, and has the advantage of not being tied to a specific programming language.

If only there was a standardized format that combined these advantages, without all that XML bloat. There is! Try YAML.

XML's big win is supposed to be its semantics: it tells you not only what data you have, but what sort of data it is. This allows you to create all sorts of dreamy scenarios about computers being able to understand each other and act super intelligently. In reality, it leads to massively bloated XML specifications and protracted fights over what's the best way to describe one's data, but not to any of the magic.

As my all time favorite Slashdot sig said: "XML is like violence: if it doesn't solve your problem, you aren't using enough of it."

I just searched Google for YAML:

YAML Ain't Markup Language

A straightforward machine parsable data serialization format designed for human readability and interaction with scripting languages such as Perl and ...

YAML Ain't Markup Language? Call me when they grow up.

This is the most pointless article I've seen linked from slashdot in a long time (and yes, I've seen a lot of crap here). What is the point of posting a run of the mill tutorial on something that's been covered many times before?

Having spent a lot of time playing with this crap lately, can I just butt into this pointless thread and say screw XML, use YAML or JSON instead. XML is a steaming, clumsy overrated turd. I benchmarked XML::Simple against YAML::Syck - the latter encoded 2.5 times faster and parsed nine times faster than XML::Simple. The syck library is indeed aptly named.

"Leverage the power of XML" by deprecating it wherever you can for a more sensible cross platform format.

</rant>

• "How to use models in migrations" - Rails uses the "Model-View-Controller" structure for application architecture. It also offers scripts which automate the creation of new models: basically, you type "script/generate model modelname", and it drops in files for model code, unit tests, et cetera. Rails also offers a method for making updates to your application's database schema called "migrations." Every time you generate a new model, it will also create a dummy "migration" into which you can enter the code necessary to update your database, regardless of the specific type of database you're running (Informix, MySQL, Oracle, Postgres...).
• "Integration testing as a DSL" - In Rails parlance, an "integration test" is a test which spans multiple models, controllers, and views. DSL, or "Domain Specific Langage," is a buzzword which basically means "a language specifically tailored to a certain task." It refers to the phenomenon some that Rails code, especially the integration test code, doesn't really scream "I am a Ruby program" to you - the method calls have evolved to the point where they look like a whole new language perfectly suited for a specific task. (That's the claim, anyhoo.)
• "Great YAML tricks for use in fixtures - YAML stands for "YAML Ain't Markup Language." It's a very simple way of representing data structures in text. Rails uses YAML for unit test fixtures: that is, your testing database can be populated with information from YAML files. Interestingly, the test fixtures can have Ruby code embedded directly in the YAML, enabling you to do stuff like iterate over hundreds of similar items. The embedded Ruby code is what makes the "great YAML tricks" possible.

Take a look at YAML. That looks programmer friendly.

Eivind.

JSON itself still suffers from much bloat, and aren't always easily readable by humans. That's why we have additional structured data formats, including YAML.

Issue 8 of the ZeroC (creators of the Ice RPC protocol) linked to an active discussion in the rpc blogosphere on the legacy of CORBA, the fate of SOAP, and the age old problems of RPC:

* exhibit A: 11:40 Oct 3, 05: Mark Baker claims CORBA was a technical failure ( http://www.markbaker.ca/2002/09/Blog/2005/10/03#20 05-10-ws-corba )
* exhibit B: 15:38 Oct 3, 05: Steve Vinoski of Iona (leading CORBA vendor) begs to differ ( http://www.iona.com/blogs/vinoski/archives/000214. html ); a long discussion including Michi Henning from ZeroC ensues in the comments, including:

Even if I do define WSDL that is "loose" and makes lots of things optional, that typically doesn't help me. Loose coupling isn't of interest just for its own sake, but is of interest because people are looking for a way to solve the versioning problem: how can I evolve a distributed application over time without breaking everything that is deployed already, and without having to recompile and redeploy the universe? If I define WSDL that is "loose" to start with, so I get the loose coupling I so much need, by implication, I know in advance how the application will evolve: I put the "loose" bits in the WSDL definitions where I expect future variation in the data. But real life doesn't work that way. None of us is prescient and, as a rule, what makes the versioning problem so hard is that we *don't* know how an application will evolve in the future. In other words, people who say that I can solve the problem by writing "loose" WSDL are kidding themselves: the real world is not cooperative enough for this to work.

* Michi Henning

It's odd that CORBA should end up being sidelined by most of its original supporters, in favour of a supposedly simpler and cheaper system that ends up being frantically complicated (well over 100 related specifications, and counting) and far more expensive. But that's business for you!

* Tom Welsh

* exhibit C: 23:05 Oct 13, 05: Ted Neward discovers and enters the discussion ( http://blogs.tedneward.com/CommentView,guid,070274 e8-ccfd-4ebd-87b5-494564c39b77.aspx )

And here is another prediction: once people get over their current fixation with loose coupling, they will finally realize that, to get loose coupling, I don't need loose type systems that throw away compile-time type safety, and I don't need support at the protocol level at horrendous cost in performance. All I need is intelligent system design, a middleware that offers a workable implementation of multiple interfaces (check out Ice facets), and domain-specific standardization. With that, I get type safety, flexibility, and performance.

* Michi Henning

* exhibit D: 17:32 Oct 22, 05: Ken Horn comments on the issue ( http://kendes.blogspot.com/2005/10/loose-coupling- corba-vs-ws.html )

Links

* PEPt - An Architecture for Adaptable Remoting Systems ( http://haroldcarr.net/pept/ )
* YAML ( http://www.yaml.org/ )
* A Conversation with Roger Sessions and Terry Coatta ( http://www.acmqueue.com/m

Streaming XML parsers definitely would raise an error on the lack of well-formedness if you requested that portion of the document... The trick is whether only a subset of the document needs to be read or not. A SAX-based parser is the classic example, with a parser available for JavaScript.

All I can do is wish that there was a sane, well-crafted, easily-parsed, fault-tolerant binary specification which enjoyed the same ubiquity.

Well, it doesn't solve all of the above, but YAML is a great alternative, I think, particularly for config files or anything human readable. It doesn't quite have the ubiquity or breadth of support for parsing/querying, but it's got uses.

This long post is relevant to today's article because many OO languages still have objectStore methods that save the internal state of the object to disk.

Indeed they do, but things are perhaps getting better. Ruby, for instance, is switching to use YAML for this, a standard that is open, human-readable and terse, the two latter much more so than for instance XML. YAML has features specifically designed to allow object persistance for any language as well as persistance of any data.

It works nicely without creating lock-in problems. Any language with a YAML parser (and most have one by now) can get at the data easily, and even without the YAML specification it's usually obvious how the data should be read just from looking at it.

Hear hear! XML is a complete waste of time. I just don't understand why everyone and their brother is so gung-ho about XML. It's ugly to humans and ugly to computers (not completely trivial to parse). Before anyone implements something that uses XML they really need to take a look at YAML.

When dealing with XMLHTTPRequests, JSON is the only reasonable way to communicate with Javascript. I often just use plaintext, too, and parse with a quick regular expression. It much better than sifting through the XML tree with the clunky DOM interfaces.

I've used all 3 techniques (JSON, plaintext, XML) when building my gaming site and I can tell you that for returning messages to javascript from XMLHTTPRequests, JSON kicks XMLs butt any day of the week.

-David

You can move anything over HTTP, and as long as the receiving end understands you, you'll be OK. You can move INI files if you want. But some people prefer to use existing infrastructure (stable/tested parsers, WS-*, schema validation and so on) so as to avoid reinventing the wheel. Reinventing the wheel is expensive. So you take a small hit on the badwidth. Most people are not Google so they don't have to worry about measuring transport bandwidth overhead in terabytes and spending a year doing characterization testing.

They use XML because they never heard of YAML or other more appropriate solutions for their configs.

Like many others, I fell for the XML hype (and I even got XML Developer certified by IBM) and I have about $200+ worth of XML-related books.

Despite this, I use YAML 95% of the time in new projects because it is much more practical than XML. Think of YAML as providing 80% of XML benefits while being much more friendly to hand-editing in plain text editors (which is what many of us do with config files).

And no, I'm not involved in yaml.org or any of their projects--I'm just a satisfied developer who found YAML when I started using Ruby this year (which has built-in support for YAML).

Try it and see your productivity skyrockit. YAML will make you more productive.

http://www.yaml.org/
http://www.ruby-lang.org/

In my opinion, XML is a lousy design for human text editing. Way too unvieldy. Look at e.g. YAML (http://www.yaml.org/) for an example of how to do this more human-friendly (and with less waste for the machines involved.)

Alas, XML became a standard and Apple use it all through OSX, so it's reasonable that they use it here, too.

Eivind.

Get over the XML-is-a-hype. Try to look at the benefits neutrally, then use what's best to do the job.

OK, I did. XML still sucks. If you take away the hype, YAML appears to be a much better solution for configuration files. It provides the benefits of XML you mention, but is simpler, easier to read, and is more consistent and line-based so it's even more "grep-happy" for you.

In this application, XML's hype seems to be the *only* thing going for it.

I haven't, but I imagine it's exactly the same problem you'd have doing Java in a "plain vanilla text editor" -- only in Lisp the closing parens are all ), where in Java it's a combination of ) ] and }. I *have* tried to debug Java in NOTEPAD.EXE, and all the different types of close-paren *do* screw me up.

I don't think the moral of this story is "don't use Lisp/SGML", or even "make closing tags really verbose". I think the moral of the story is either:
- don't use a "plain vanilla text editor" for debugging "deeply nested" code -- use a real editor -- or:
- use a languages like Python and YAML that don't *need* closing parens in the first place.

Since this is slashdot, I now expect several people who have never written a line of Python in their lives to respond, saying how Python's use of indentation is brain-dead. *Yawn*.

(Oh, and the parent was probably trying to say "minimized end-tags like <tag/text here/", but forgot to escape his <.)

XML was monocase until quite late in its design, when we ran across this ugliness. I had a Java-language processor called Lark - the world's first - and when XML went case-sensitive, I got a factor of three performance improvement, it was all being spent in toLowerCase().- Tim Bray

Not that surpising - seeing XML uses unicode. Making unicode case-insensitive is hard. I do hope we get a better "universal" serialisation format soon, though. YAML looks good.

• If I were in charge, I would be a little less coy about the .dfm file and its textual representation. I may also consider a standardized Pascal syntax for describing graphs and data -- there is this thing called VHDL that has an IEEE standard and is used for hardware design, but it seems perfectly suited for a Pascal-syntax answer to XML. And for you C-syntax proponents, there is this thing called Verilog.

And there is YAML. It's already quite popular.

What about using YAML

uh, you forgot to mention YAML http://www.yaml.org/ lol

Of course, there is already a Data Description Language with whitespace significance, vying to replace XML: YAML. And, interestingly enough, this particular instance of style-as-substance seems to be quite popular with the Ruby crowd.

I've started using YAML for config files for anything I write. YAML is far more readable than XML and it's still machine parseable.

http://www.yaml.org

Dave

Reading through the posts on this board, I tend to agree with the criticisms about XML. It's a big dreadnought of a specification when, in most cases, a nice light corsair or even single-seat fighter would do the trick. Still, I would normally be inclined to say of XML what is said about Democracy: it's the worst system out there, except for all the others.

Then I found YAML. Long and short, YAML is very lightweight, eminently readable, easy to use (parsers exist in multiple languages) and a pleasure all kinds of projects that require data serialization. Where XML branches off into other types of uses, like XSL programming, YAML doesn't really compete. I find this to be a strength, actually, because once you've used YAML and seen it in action, XSL seems like a big, fat add-on. But for those that rely on XSL and other things, YAML won't do the trick.

But if all you need is data serialization in a compact, easy-to-read, easy-to-use package -- and this, in my opinion, is by far what XML is most used for -- then YAML is great. Give it a shot.

As for XML. I used to hate it with a passion. Now I still hate it, but I'm less passionate. The creators of XML are ambitious people, and they tried to do something in that spirit. It works, basically and XML doesn't deserve *all* the bad press it gets.

If I'm not mistaken, Ruby is the first language to include built-in support for YAML!

Thanks to Matz for such a great language!

See www.yaml.org. YAML is an project that evolved from SML-DEV. SML-DEV attempted to define a subset of XML that would be both useful and simple enough to avoid XML's biggest headaches.

After much wrangling (this was about the same time XML came up with the namespaces rules that blew up any chance for a reasonable data model for XML), the best we could come up with was Common-XML (http://www.simonstl.com/articles/cxmlspec.txt). While it does avoid some of XML's built-in boobytraps, and I'd strongly recommend any XML user to read it, it doesn't solve the inherent problem - XML is not a good match for common programming data structures, and at the same time *data* XML files are not very human readable.

It isn't XML's fault, really; XML is a great mark-up language. However, it sucks as a data serialization languege, for the above reasons. So, figuring one should use the right tool for the right job, two of us SML-DEV people (Clark and myself) decided to give up on XML compatibility and try to design a data serialization language from scratch. We immediately combined efforts with Brian, the author of Perl's Data::Denter (and Inline::C).

The result is YAML (YAML Ain't Markup Language). After almost two years of working on it, the spec has stabilized and is as good as frozen (it is in "last call" and we plan on announcing a release candidate in April), there is healthy participation in the mailing list, implementations in Perl and Ruby, and active work on additional languages.

YAML is great for data serialization, configuration files, messaging, etc. Take a peek - you might like what you see. (OK, this is a shameless plug for my open source project. That's a valid use for Karma if I've seen any...)

One of the biggest problems with XML is that it's information model is quite complex; far more complex than what the average problem needs. When looking for an alternative, you should look for solutions which have addressed this fundamental problem.

Those who like Python should look at YAML

You may get interested in YAML.

I'd also recommend looking at YAML