Hacker News Reader

Comment by cryptonector | Hacker News Reader

XML is superior to JSON for text documents. Far superior.

If you want to build a JSON for text, then start by considering how to map XML to JSON. Many attempts at that exist, most terrible because the author didn't understand ordering requirements of child nodes (in XML they are ordered as they appear, but in JSON that's only true of arrays). The only reasonable way to map XML to JSON is to use arrays for all child nodes of any node, using objects at most just for things like node attributes and PIs.

I've done a fair bit of XSLT and jq programming. I understand the appeal of JSON here: jq is much pithier than XSLT/XPath! But first you have to get a bunch of things right that XML already got right.

EDIT: Once you have a very complex document schema, its mapping onto JSON will complicate any jq programs to the point where the advantage JSON has over XML as to DSLs disappears. XML simply is the right tool for documents.

View on HN

It is the circle of life: XML is a fine format for structured text, but some people decided it should be used for everyhing - tabular data, key-value sets, programming code what have you. Then somebody figures out an alternative (JSON) is much simpler and concise for some particular use cases. And then some people decides that JSON should be used for everything. It wont be long before someone propose JHTML - HTML in JSON-notation. And of course JCSS.

We programmers love simplicity. The selling point of JSON was that it was really simple compared to the pile of specs which XML had become. But after a while it turns out people actually needed the features the XML standards provided: validation, querying etc. And a similar set of specs grow around JSON.

My guess for the next revolution: Some people figure out it is really annoying to have to quote keys in JSON and that JSON does not express expressions or DSL's very well. So s-expressions comes into fashion. And we get sexpr-schema, sexpr-query, and at some point someone will propose sexprs as a standard for structured hypertext.

> XML is superior to JSON for text documents. Far superior.

Why do you think so? Is it because most structured texts are Trees?

If so I understand the appeal. Because hey, HTML is perfect isn't it? Except, it's really not. While HTML is great for rendering, it sucks at WYSIWYG editing.

Example:

    <p> This is <span style="font-weight:underline;">a <b><i>formatted </b>text</i>content </span> </p>

Now good luck, finding/changing the formatting information for the 9th character ;)

The funda is - rendering is easy with trees, nodes and children. Editing though is easier with working with indices than traversing trees.

https://prosemirror.net/docs/guide/#doc.structure

http://marijnhaverbeke.nl/blog/prosemirror.html#the-document

These write-ups are interesting reads on the topic.

Perhaps I don't understand you, but HTML is not XML. There was an attempt to make HTML a form of XML a while ago, but people mostly forgot about it for no good reason.

Sorry, it came off that way. Yes, HTML is not XML. I meant any XML-ish representation of rich-text contents. Which means every formatting block makes the tree grow one level deeper.

If you decided you don't want that, you could come up with a XML document format that doesn't allow nested formatting blocks. So your point seems awfully moot.

In fact, even with HTML you could remove all the nesting from formatting blocks on load and either put them back on save or leave it flat (assuming you use CSS and not semantic style tags).

I said nothing about HTML though, did I.

JSON and XML are both difficult to edit by hand, so don't do that. JSON, arguably, is harder to edit by hand because there's no CDATA, so you have to know how to escape characters, especially newline.

Both are tree-like structures. Why would one be better than the other? Well, XML has a long history of use and development for text documents, whereas JSON does not, so right there, that argues against JSON.

Does XML suck for WYSIWYG editing? I don't see why it would suck more than, say, TeX. LyX -a WYSIWYM editor for LaTeX- exists, and it can output XHTML using a LyX-specific schema. I'm sure LyX could easily have been built using an XML format from the get-go. You've not made any arguments as to why XML suck for WYSIWYG editing -- the example you pasted surely is meaningless in a WYSIWYG editing since that kinda implies having... a WYSIWYG (GUI) editor. And surely JSON will take more ceremony to express 'bold and italic' than XML, and not much less ceremony than XML to express 'use this specific font' (where the font's name alone is lengthy enough).

All you've done is expressed a preference for encoding details that no one really cares about, and you may not have stopped to really learn and understand XML, so your preference is leading you into making a number of mistakes the most important of which is NIH reinvention. Each NIH reinvention adds a fair amount of cognitive load for the rest of us, and adds development and maintenance burdens that never go away. Please don't do this. Innovation is very important, of course, but don't blindly reinvent to innovate.

I agree. I may have misinterpreted the original comment. Yes, in that way XML is indeed a better way to put it.

I'd still stand by my opinion on not-making formatting information as separate tags and blowing the tree one level deeper. Preserving formatting options as index based properties would make editing APIs simpler and convenient.

Again, this is nothing in regard to the original comment. Just putting it out there.

XML per se is great for storing tree like structures. However, it's not actually XML that's bad, but content editable, which is what most editors were using until recently.

In content editable, the visual information is not one to one transferable to a single html document, which, in turn, means not transferable to a single XML representation (and in all likelihood, the html is what is used as the representation, not a transformed XML document).

With Json representation , the content editable method is no longer the path of least resistance. Building out a proper renderer (whether in canvas or dom) means you end up removing most of the content editable issues.

JSON is harder to edit manually, honestly. Don't do it. Use an editor that supports editing the format.

Nobody is talking about editing the JSON directly. They are talking about programming a wysiwyg editor to the JSON data model.

I would say XML vs JSON makes little difference to the complexity of an application (e.g., an editor) using it.

manipulating JSON (really, just plain native language objects) is way more straightforward than manipulating the XML dom. The purpose of formats like this is to make inexpressible the kinds of documents that result in difficult to untangle bugs, and frustrating UI behaviour. See this article about how Medium's editor was designed for some essential background of the motivation for this JSON format

https://medium.engineering/why-contenteditable-is-terrible-1...

Until recently? What are most editors using now?

"contenteditable" is an HTML5 (!) attribute defined by the XML hating HTML5 group. Right?

> While HTML is great for rendering, it sucks at WYSIWYG editing.

Nobody says you have to operate on it in that format. You read it into internal structures and output those internal structures to HTML. I don't expect an editor to maintain a 1-to-1 relationship with the storage format while operating in memory.

Because not all markup is structural.

>> XML is superior to JSON for text documents. Far superior.

> Why do you think so? Is it because most structured texts are Trees?

XML allows for mixed contents. If I am reading this proposal right to change

    <span>Some <b>formatted</b> content.</span>

into

    <span>Some <b>forma<i>t<i/>ted</b> content.</span>

you would essentially produce the equivalent of Some formatted content.

as the "text" field cannot contain childrens.

which is what happens at https://react-prosemirror-example.now.sh/

wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww ->

{ "type": "doc", "content": [ { "type": "paragraph", "content": [ { "type": "text", "text": "wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww" }, { "type": "hard_break" } ] } ] }

and with bold in the middle

{ "type": "doc", "content": [ { "type": "paragraph", "content": [ { "type": "text", "text": "wwwwwwwwwwwwww" }, { "type": "text", "marks": [ { "type": "strong" } ], "text": "w" }, { "type": "text", "text": "wwwwwwwwwwwwwwwww" }, { "type": "hard_break" } ] } ] }

This is not to say that is is a bad format, essentially XML does the same from an API level and maybe being explicit about it is good, but for sure is feels a bit different (again, do not want to express a better or worse).

Overall I am happy from the simple fact that it does not have the overused "Markup Language" in the name.

Your example shows why XML parsing is so strict.

If I add your example into my XQuery processor, I get: "Different start and end tag: ...."

Also, HTML != XML.

An HTML parser may forgive that error, an XML parser clearly does not.

Also, with JsonML there is a lossless mapping from XML to (array based) JSON (and vice versa), which makes the project linked here, totally redundant.

For JSON querying, checkout JSONata(http://jsonata.org/ - Inspired by the location path semantics of XPath 3.1) . It was created by Andrew Coleman(Part of W3C XML Query WG).

I seem to have reinvented parts of that in python by total happenstance with my latest little project[0]. Have to check out the docs some more to see what ideas I can steal.

[0] https://github.com/eponymous/python3-property_tree

Reply on news.ycombinator.com