Live data from Hacker News

In Defense of COS, or Why I Love JSON and Hate XML

jimpravetz.com

21–30 of 46 posts

Re: In Defense of COS, or Why I Love JSON and Hate XML

#21
post #18

the main arguments are about syntax. there's no mention of namespaces and schema are dismissed because the author didn't use them. no mention of tools for automated processing. this is not a very good article, in all honesty. he doesn't like the syntax, but doesn't seem to consider that different technologies can be suited to different problems, or that he simply hasn't experienced the kind of uses where xml works we…

Agreed. I like JSON and I think it's the better choice for serialization and data exchange in many cases where XML is used today, but pretending it's the magic alternative to anything you could also do with XML is crazy, and it only shows a very limited understanding of what XML actually is. Transformations, schema checking, xpath queries, well defined linking and embedding, a host of tools that support applications…

YAML, which is a superset of JSON, adds the potential to be just like XML but less verbose. It never went through the same kind of hype though, so the tooling is not nearly as pervasive.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#22

Earlier quoted context omitted.

Yes, But I would claim that by being designed for many jobs in a sloppy way, XML became a terrible tool for all jobs. Json is a good replacement for XML in some of the application for which some folks foolishly targeted XML (I worked on a server back in the day that really did process five times the data 'cause of our use of XML for interchange - as was the new standard at the time , remember "XML everywhere!"?). Htm…

'XML became terrible for all jobs' ... you do realize that there are literally hundreds of billions of xml encoded documents out there, happily doing what they are supposed to do ... not trolling; but lets put some of the comments in context for what they are. XML in its original role of extensible markup is thriving and completely successful ... as I previously mentioned, I am glad we are not slinging around angle b…

'XML became terrible for all jobs' ... you do realize that there are literally hundreds of billions of xml encoded documents out there, happily doing what they are supposed to do ... not trolling; but lets put some of the comments in context for what they are.

I sure do. I perhaps should have conceded that once you get up to the level of Large Enterprise Monstrosities (LEMs), you have something almost by definition "terrible" (or at least messy from the viewpoint of smaller, more coherently architected systems) and thus in that situation, I might not, maybe, have any basis for criticism.

But still, one thing I'd speculate is, that that one attribute/value ambiguity problem just might be sooo bad that even in the realm of whatever-monstrosities-that-have-meld-together-messy-stuff, XML would do better replaced by a different whatever-monstrosity.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#23
post #18

the main arguments are about syntax. there's no mention of namespaces and schema are dismissed because the author didn't use them. no mention of tools for automated processing. this is not a very good article, in all honesty. he doesn't like the syntax, but doesn't seem to consider that different technologies can be suited to different problems, or that he simply hasn't experienced the kind of uses where xml works we…

Agreed. I like JSON and I think it's the better choice for serialization and data exchange in many cases where XML is used today, but pretending it's the magic alternative to anything you could also do with XML is crazy, and it only shows a very limited understanding of what XML actually is. Transformations, schema checking, xpath queries, well defined linking and embedding, a host of tools that support applications…

I must be one of the few who thought that XSL was a great way to build visual interfaces to data, in browsers that support XSLT (this was an area where IE had an very early advantage over other browsers, not sure what the state of things is today). Sorting, filtering, drilling down... all trivially easy and declarative with XSLT, once you groked xpath. Yeah it was verbose, but otherwise great.

There are some similar approaches for JSON data now, I think... but none are standards-based AFAIK, meaning they are mostly single-vendor or project solutions.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#24

Earlier quoted context omitted.

Yes, But I would claim that by being designed for many jobs in a sloppy way, XML became a terrible tool for all jobs. Json is a good replacement for XML in some of the application for which some folks foolishly targeted XML (I worked on a server back in the day that really did process five times the data 'cause of our use of XML for interchange - as was the new standard at the time , remember "XML everywhere!"?). Htm…

'XML became terrible for all jobs' ... you do realize that there are literally hundreds of billions of xml encoded documents out there, happily doing what they are supposed to do ... not trolling; but lets put some of the comments in context for what they are. XML in its original role of extensible markup is thriving and completely successful ... as I previously mentioned, I am glad we are not slinging around angle b…

The lack of user-defined tags and attributes (ignoring data-* for a minute because it's different) is what makes HTML such a more pleasant document/markup language than XML.

XML schemas are hard because allowing people to define an ad-hoc ordered hierarchical parsing structure is hard, so most people don't do the schema part (or ignore the schema in the real world) resulting in ambiguity in the rules about what sort of constructs are allowed in the document or what they mean, resulting in XML formats that aren't really interchangeable.

HTML5 relieves this by having only one markup format that's actually specified with a real common understanding instead of a multitude of formal and informal markups. Evidence that the world needs more than one markup format is thin on the ground, what most people need is the ability to locally distinguish between and identify things, and class and id are complete and minimal for that job.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#25

Earlier quoted context omitted.

'XML became terrible for all jobs' ... you do realize that there are literally hundreds of billions of xml encoded documents out there, happily doing what they are supposed to do ... not trolling; but lets put some of the comments in context for what they are. XML in its original role of extensible markup is thriving and completely successful ... as I previously mentioned, I am glad we are not slinging around angle b…

It's a shame AJAJ is harder to pronounce than AJAX. We need a new term CEOs can learn to say. Then when they start demanding we use this latest technology, we'll be ready.

Feel free to excise XML from any buzzword by claiming the X doesn't stand for XML, it's a free variable. "Our X is JSON"

Re: In Defense of COS, or Why I Love JSON and Hate XML

#26

Dings XML for crappy commenting syntax then gives JSON a pass for not supporting comments at all. I love JSON, but it does have it's issues.

On the other hand, comments were explicitly excluded from JSON by Crockford (with the thinking — probably correct — that they'd be abused to embed such things as parsing directives or other out-of-band content)

I believe he was correct at the time, he removed them once people started using them for parsing directives. (JSON hasn't always been frozen)

Re: In Defense of COS, or Why I Love JSON and Hate XML

#27
post #17

Earlier quoted context omitted.

JSON not having comments is a benefit when used for it's primary purpose: information exchange. JSON is not a great format for configuration files or static documents even though it's increasingly used for it.

YAML is better suited for configuration files.

Yaml is not good for configuration files because it is not easily human-editable. It seems "easy" but meaningful whitespace is a cluster-fck.

Edit: I have been looking for reasonable configuration file formats for a while. Json actually has pretty bad human-readability at any scale because of its quoted key-values. Yaml is easily readable but when a user tries to change anything, things go to hell. The humble ini-file has won so far. It's limited and not fully standardized but it is human readable and human writable. I'd love see something better but human readability/writable is going trump all sorts of cleverness.

Edit2: From http://en.wikipedia.org/wiki/YAML "The specific number of spaces in the indentation is unimportant as long as parallel elements have the same left justification and the hierarchically nested elements are indented further."

Yeah, a user of your software is going to be able to understand when they mess up on that rule, riiiight. Screw Yaml.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#28

Dings XML for crappy commenting syntax then gives JSON a pass for not supporting comments at all. I love JSON, but it does have it's issues.

I don't know that it applies here, but sometimes it is better to not have a feature at all than to have it badly.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#29
post #17

Earlier quoted context omitted.

JSON not having comments is a benefit when used for it's primary purpose: information exchange. JSON is not a great format for configuration files or static documents even though it's increasingly used for it.

YAML is better suited for configuration files.

I wish there existed a popular config format that was somewhere between YAML and JSON. In my current nodejs project I sometimes use js files for config because js supports comments and is more lenient on syntax then JSON. I prefer using { } to group objects, rather then YAML indenting, but otherwise am okay with YAML and only don't use it because the parser is not part of Javascript or nodejs.

Re: In Defense of COS, or Why I Love JSON and Hate XML

#30

Dings XML for crappy commenting syntax then gives JSON a pass for not supporting comments at all. I love JSON, but it does have it's issues.

Explicit is better than implicit. If you have to explain something you've probably written the JSON wrong.

You can always do this:

    {
        'people' : 10,
        'desc': 'People who will attend'
    }
Post reply on HN