Hacker News Reader

Comment by wccrawford | Hacker News Reader

"XML deals remarkably well with the full richness of unstructured data."

What? No, it doesn't. XML has even more structure than JSON does. Unless you're using it improperly, and the you're negating all the advantages that XML was supposed to bring.

It wasn't for 'mixed content'. It was for system interoperability.

The advantage that XML brings over JSON is that you can have an external document that you can use to validate any XML you're sending or receiving. You can guarantee it's formatted correctly. JSON provides no such guarantee.

Not that that's necessarily a bad thing.

View on HN

It only provides that guarantee because the parsers have agreed to do so (and not all do, nor do they do so identically). It's a guarantee by communal agreement, nothing more.

There's no reason a JSON format can't do the exact same thing. JSON-RPC, for instance, defines its own rules on top of JSON which anything using it must conform to. How hard would it be to make a set of JSON interchange rules which specify external schema documents?

edit: answer:

  {json_strict_version:1, schema:{external:[url,url], internal:[{schema},{schema}]}}

If I'm reading you right, you're saying that XML only provides a guarantee because of an abstract agreement between parsers? Nonsense. XML has a specification for what constitutes a well-formed document and an XML Schema defines rules that assure validity. XML may be verbose and the libraries may be a pain to work with (though there are some well-written ones out there) and there may be other flaws you want to bring up, but this is not a defensible point.

XML spec: http://www.w3.org/TR/REC-xml/#sec-conformance

>Conforming XML processors fall into two classes: validating and non-validating.

Yup, that's a guarantee alright. A guarantee consisting of the people who wrote the parser agreeing to write DTD-parsing code. Or not. Depends on your parser.

It has a specification for validation because a specification for validating it has been written, based on agreement of the specification and implementation by the parsers, not because XML has some inherent, magical validatability quality.

edit: this is all on top of that a spec is just a spec until someone implements it. Plenty of specs have been chucked because others did something else, or have attributes which nobody implements (how many email forms accept the full RFC-compliant email set?). A spec is an abstract agreement.

I have never seen anything that implements validating XML parser as intended by specification and is actually used in production code. Half of XML consumers I've seen in production implement namespaces in various broken ways (like depend on exact values of prefixes)

Well-formedness is a separate issue from validation. All XML parsers are required by the spec to reject documents that aren't well formed. You can think of it as the lexical analysis rules for XML, whereas validation is the parsing (if that helps).

I don't see the grandparent as pointing out a flaw in XML so much as pointing out that this isn't something that JSON can't be made to do. The only thing stopping you from having a "JSON schema" is that such a thing hasn't been blessed by a standards committee. There's nothing stopping you from writing a library that will validate JSON based on a JSON schema of some type.

Sure, and you can write JSON editors and namespace extensions and query languages and libraries with extensions for those query languages and then you find out that the JSON schema language isn't very good; so you make a new one and editors for that new schema language, and then you write a language to translate one JSON document into another one, with a schema for that new language of course, in all 5 of the flavors of schema languages.

And then we're 10 years into the future and we're seeing this exact same article again, except with s/JSON/some simple JSON replacement/g and we're back to square one.

JSON has its uses, it's quite nifty in its ease of use for doing ajax stuff, but imo the point of the article was to point out that xml vs json is a nonsense comparison much like 'sql' vs 'nosql' databases.

You mean, like they did with DTDs, RelaxNG, and XSD (and probably half a dozen ill-conceived solution that died a well-deserved death)?

Different XSD implementations do have slightly different ideas on interpreting the schema. (e.g., if your data has a bunch of A tags, then a B tag, then another bunch of A tags, do you include two occurs:unlimited statements for the A's or just one?)

By the way, Javascript works just fine as a "query" language for JSON. Not as good as XPath or XQuery work for XML, but definitely better than any XML DOM manipulation in Java or another language would.

Yes those are what I meant - my point was that this whole evolution needn't be repeated with JSON. Let's keep JSON for the things it's good at, and keep it simple, and keep XML for the things it's good, with all the complicated things we have for it now anyway.

There's json-schema[1] if you feel like validating your json payload

[1] : http://tools.ietf.org/html/draft-zyp-json-schema-02

It really seems that a lot of people in this thread don't get the meaning of "mixed content". That's where you have plain text mixed with tags, and it's difficult to represent with JSON. If you don't think so, I'm curious to see a good way of doing it.

Here's a link that illustrates this concept:

http://seanmcgrath.blogspot.com/2007/01/mixed-content-trying...

It's not as persuasive as it could be, but it gets the idea across.

Only partially. Take a look at DOM interpretations for HTML's flavor of XML: that sort of [b][text]a word[/text][/b] markup is precisely what it interprets [b]a word[/b] as. Because that's what it means.

And in any case, in order to handle truly inline content you've still got to correctly detect such in-line code, and label it as separate from regular text which just looks like inline code. Which means escaping. Which means

  "text {b:'bold text'} more text"

is the same solution, with the same problems.

>Here is XML's sweet spot (using square brackets to keep everything un-mungable by the angle-bracket chewers in my current tool chain):

Sweet spot, in that parsers usually just assume everything which looks like code is code, even when the spec allows for other ways, forcing people to fake it with things like square brackets.

edit: whups. Editors, not parsers, are primarily responsible for such mangling, by making it hard to insert code-as-text. The problem with inline markup still exists, however.

An XML document is mixed content in the sense that it can be validated, signed, partially encrypted (perhaps by multiple actors), can be wrapped by a header, and augmented for application level routing. [edit: where each of these actions may mix-in content with the original document.] And all of this can be done in a standards compliant way.

Now the standards can totally suck - they can be improperly implemented - and they can be difficult to make performant... But those are largely issues of implementation unrelated to the core XML and XML namespace specifications.

It seems unlikely to me that JSON could reasonably be purposed to those use cases...

> It seems unlikely to me that JSON could reasonably be purposed to those use cases...

Since any XML document can in theory be converted into a complete JSON representation I do believe that nothing is keeping people from doing exactly those use cases. You're right in asserting that this isn't happening in practice with JSON. I allege the reason for this is that XML isn't really used for these kinds of operations either. Sure, the XML working group put out a stunning amount of "standards" that prescribe these conventions, but in practice NONE of it actually works across vendors without heavy intervention and some pretty shocking compromises in application code. Most complex XML products are not actually that interoperable, they mostly just work because one or more communication endpoints are basically faking compliance of their interfaces.

"Since any XML document can in theory be converted into a complete JSON representation"

How? (apart from a char array...)

A DOM is just a tree of nodes, each of which has a fixed set of fields based on its type. That makes it automatically doable if you throw enough collections of key-value pairs at it:

  # <a href="http://example.com">hello world</a>

  {
    "node-type":"element",
    "namespace":"http://www.w3.org/1999/xhtml",
    "name":"a",
    "attributes":[
      {
        "namespace":null,
        "name":"href",
        "value":"http://example.com"
      }
    ],
    "children":[
      {
        "node-type":"text",
        "value":"hello world"
      }
    ]
  }

Oh ok, yes. I think I may have misunderstood the original claim then, I thought the GP was saying that JSON had mechanisms to express all xml functionality. BTH though this still only makes sense with the XML spec laying next to it and is just notation. Maybe I'm not getting the point of the discussion, I'll just let it be ;)

Yeah, there's no agreed convention on how the infoset of an XML document (which I should have used rather than DOM) ought to be represented in JSON, and generally people don't do it (e.g., RDF/JSON isn't a direct mapping from RDF/XML, but a new format to express the same basic facts), it's just technically possible.

Think what the author meant is that XML allows documents where the structure is less predefined. It can be the markup that drives the interpretation. With a JSON payload, you need to know how the whole is structured to know how to use it, or build additional mechanisms over it.

Also XML brings other useful features like data types.

Is there a reason JSON fields can't be an object (of sorts) which defines data type, parsing rules, depth to read, circular structures, etc?

You can convert, losslessly, between XML and JSON. Doesn't that mean they have identical capabilities, though one may be easier in certain circumstances? There's no "need" in any one which the other doesn't also need.

"You can convert losslessly" – that's not the whole truth. It's an issue that there's no obvious or agreed upon way to render an XML format like ATOM into JSON, because everyone makes up their own transformation rules. Here are two distinct attempts: * http://www.ibm.com/developerworks/library/x-atom2json.html * http://code.google.com/apis/gdata/docs/json.html

Obvious or agreed-upon does not mean cannot. Google's, for instance, looks nigh-identical to what I'd have aimed for; nodes = fields, node-attributes = fields in the object on a field, node-text-content = specially-named field. It's a naive, 1-1 transformation between the two. Simple enough that I'd actually consider it the "obvious" way to do so.

IBM's, on the other hand, has a number of nonsensical statements like this:

>Because JSON is incapable of preserving any notion of a Base URI, it is unlikely that an application using the JSON serialization is capable of properly rendering markup containing relative URI paths. It is therefore important that such paths be resolved automatically during the conversion process as shown ...

Bull. Base URI is just a field, or inferred by the document's source. ie: the same as XML. Their technique is incapable of translating a Base URI, it has nothing to do with JSON. Theirs also cannot handle namespacing, while Google's is simple, and almost identical to how XML does it: namespace$field: value.

Well... as far as I know, json by itself is just objects with fields, these fields are either objects or string values. Of course you can do all you mention but you'll have to build a convention on top of json. So reading these json payload would require more than just knowledge of json, it would also require knowledge of what are these fields or objects that carry special interpretation meaning and what to do about it.

A lot of these conventions are available the XML standards. Of course if they had started with something like json the result would be less verbose but maybe not that simple either.

Reply on news.ycombinator.com