35 ms·

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

> 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: This is a formatted textcontent 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 https://prosemirror.net/docs/guide/#doc.structure http://marijnhaverbeke.nl/blog/prosemirror.html#the-document http://marijnhaverbeke.nl/blog/prosemirror.html#the-document These write-ups are interesting reads on the topic.

frenchy 8y ago
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.
- lewisjoe 8y ago
  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.
  - wvenable 8y ago
    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).
cryptonector 8y ago
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.
- lewisjoe 8y ago
  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.
- chii 8y ago
  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.
wvenable 8y ago
> 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.
specialist 8y ago
Because not all markup is structural.
kiriakasis 8y ago
>> 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 Some formatted content. into Some formatted content. you would essentially produce the equivalent of Some formatted content. as the "text" field cannot contain childrens.
- kiriakasis 8y ago
 which is what happens at https://react-prosemirror-example.now.sh/ 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.
zmix 8y ago
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.

frenchy 8y ago

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.

lewisjoe 8y ago
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.
- wvenable 8y ago
  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).

cryptonector 8y ago

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.

lewisjoe 8y ago
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.
chii 8y ago
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.

wvenable 8y ago

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

specialist 8y ago

Because not all markup is structural.

kiriakasis 8y ago

>> 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 Some formatted content. into Some formatted content. you would essentially produce the equivalent of Some formatted content. as the "text" field cannot contain childrens.

kiriakasis 8y ago
which is what happens at https://react-prosemirror-example.now.sh/ 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.

zmix 8y ago

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.