4 ms·

I am a wrong person to ask. I've never advertised XML as machine to machine format. I've used SOAP, XML configs, it was not smooth. My interaction with XML mos

I am a wrong person to ask. I've never advertised XML as machine to machine format. I've used SOAP, XML configs, it was not smooth. My interaction with XML mostly was in browser where it shines compared to HTML as application format. I have my own list in defense of XML, wrote first one [1]. Unfortunately your argument is "I don't need it" which is not a lot. Imagine Unicode instead of XML "ASCII works for me, Unicode does not fit in char, not even in wchar, surrogate pairs, access by index, wrong encoding". I mean, sure, stick to ASCII. Now, transformations, the idea was people would catch clicking quicker than real programming language. Turtle, Scratch have its place. Visual Basic has its place. Excel has quite big place. [1] http://sergeykish.com/pre-newline-preserved-in-xhtml-test http://sergeykish.com/pre-newline-preserved-in-xhtml-test

lmm 6y ago
> My interaction with XML mostly was in browser where it shines compared to HTML as application format. I have my own list in defense of XML, wrote first one [1]. If that's your best argument for XML then I'm thoroughly unconvinced. I can see the theoretical argument for the XML behaviour, but the HTML behaviour seems a lot more useful in practice - a lot of the point of using pre is to preserve vertical alignment, and with the XML approach the first line is forced to be misaligned in the source. > Unfortunately your argument is "I don't need it" which is not a lot. Imagine Unicode instead of XML "ASCII works for me, Unicode does not fit in char, not even in wchar, surrogate pairs, access by index, wrong encoding". I mean, sure, stick to ASCII. But there's a compelling argument for using unicode: a lot of characters can't be represented in ASCII, and traditional codepages don't let you use characters from multiple languages at the same time. Where's the corresponding argument for XML? > Now, transformations, the idea was people would catch clicking quicker than real programming language. Turtle, Scratch have its place. Visual Basic has its place. Excel has quite big place. But not everything has a place. Some tools are just bad, and point-and-click builders are one such thing IME.
- sergeykish 6y ago
  Thank you for feedback. HTML behavior is useful when authoring plain text <pre> foo </pre> But I write in browser, by content is DOM, HTML is a poor serialization format. Each time I save and reload it eats newline. Other arguments - </script> inside <script>, </style> inside <style>, <ul> inside <p>. It just works in XHTML, as it would in JSON, EDN etc. HTML parser is a beast [1] [2], you would have much more problems. World around us clearly states there is a need for a rich text format. Hardly anyone objects web browsers for document consumption. uBlock Origin "Block element ..." is point and click. [1] https://htmlparser.info/parser/ https://htmlparser.info/parser/ [2] https://www.w3.org/TR/html50/syntax.html https://www.w3.org/TR/html50/syntax.html

lmm 6y ago

> My interaction with XML mostly was in browser where it shines compared to HTML as application format. I have my own list in defense of XML, wrote first one [1]. If that's your best argument for XML then I'm thoroughly unconvinced. I can see the theoretical argument for the XML behaviour, but the HTML behaviour seems a lot more useful in practice - a lot of the point of using pre is to preserve vertical alignment, and with the XML approach the first line is forced to be misaligned in the source. > Unfortunately your argument is "I don't need it" which is not a lot. Imagine Unicode instead of XML "ASCII works for me, Unicode does not fit in char, not even in wchar, surrogate pairs, access by index, wrong encoding". I mean, sure, stick to ASCII. But there's a compelling argument for using unicode: a lot of characters can't be represented in ASCII, and traditional codepages don't let you use characters from multiple languages at the same time. Where's the corresponding argument for XML? > Now, transformations, the idea was people would catch clicking quicker than real programming language. Turtle, Scratch have its place. Visual Basic has its place. Excel has quite big place. But not everything has a place. Some tools are just bad, and point-and-click builders are one such thing IME.

sergeykish 6y ago
Thank you for feedback. HTML behavior is useful when authoring plain text <pre> foo </pre> But I write in browser, by content is DOM, HTML is a poor serialization format. Each time I save and reload it eats newline. Other arguments - </script> inside <script>, </style> inside <style>, <ul> inside <p>. It just works in XHTML, as it would in JSON, EDN etc. HTML parser is a beast [1] [2], you would have much more problems. World around us clearly states there is a need for a rich text format. Hardly anyone objects web browsers for document consumption. uBlock Origin "Block element ..." is point and click. [1] https://htmlparser.info/parser/ https://htmlparser.info/parser/ [2] https://www.w3.org/TR/html50/syntax.html https://www.w3.org/TR/html50/syntax.html