Hacker News Reader

Comment by lewisjoe | Hacker News Reader

> 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.

View on HN

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...

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

Until recently? What are most editors using now?

> 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.

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).

>> 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.

Because not all markup is structural.

Reply on news.ycombinator.com