4 ms·

I don't know. XML looks like a hype pushed too far. Like server side javascript, nosql, docker, kubernetes but with a strong support from the industry. It is r

I don't know. XML looks like a hype pushed too far. Like server side javascript, nosql, docker, kubernetes but with a strong support from the industry. It is really hard to gather useful parts. Entire XHTML push for the sake of it was misleading. Semantic web. Like publish data and they will come. This does not work, data should be crafted with specific consumption in mind. XSLT as XML makes sense when it is transformed with XSLT. Even than authoring is better with human readable form like RELAX NG compact syntax. What is meta and what is content defined on consumption point. XML inherited totally needless attributes that just brings confusion. Namespaces looks like a least of sins. They are useful. So what is a life in Xmlendom looks like? Documents with slight overhead for human consumption (in browser), just a few clicks to extract relevant data, a few more clicks to make parser, a few clicks to make transformation. XML plain text editing is as pointless as DOCX plain text editing.

lmm 6y ago
> Namespaces looks like a least of sins. They are useful. Well, the most immediate concrete practical problems I have when working with XML are a) in the default configuration, a lot of parsers will throw an error if they can't load the DTD over the network, which is an accident waiting to happen b) XPaths written in the most obvious way will silently fail to match anything until you've done a bunch of extra configuration to get the namespaces set up right. Maybe they're not the deepest problems, but the surface experience matters too. > So what is a life in Xmlendom looks like? Documents with slight overhead for human consumption (in browser), just a few clicks to extract relevant data, a few more clicks to make parser, a few clicks to make transformation. In my experience anyone who can actually understand those transformations well enough to maintain them would rather be using a real programming language instead of clicking. > XML plain text editing is as pointless as DOCX plain text editing. So why not something like protobuf that's easier to work with then?
- sergeykish 6y ago
  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

> Namespaces looks like a least of sins. They are useful. Well, the most immediate concrete practical problems I have when working with XML are a) in the default configuration, a lot of parsers will throw an error if they can't load the DTD over the network, which is an accident waiting to happen b) XPaths written in the most obvious way will silently fail to match anything until you've done a bunch of extra configuration to get the namespaces set up right. Maybe they're not the deepest problems, but the surface experience matters too. > So what is a life in Xmlendom looks like? Documents with slight overhead for human consumption (in browser), just a few clicks to extract relevant data, a few more clicks to make parser, a few clicks to make transformation. In my experience anyone who can actually understand those transformations well enough to maintain them would rather be using a real programming language instead of clicking. > XML plain text editing is as pointless as DOCX plain text editing. So why not something like protobuf that's easier to work with then?

sergeykish 6y ago
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