5 ms·

XML was horrible for data interchange, configuration, and all the other crap people used it for. It's one of the best tools for marking up content. It's a Mark

by bphogan 12y ago

XML was horrible for data interchange, configuration, and all the other crap people used it for. It's one of the best tools for marking up content. It's a Markup Language! If you've never used XSLT you really should look at what it can do. Because I can transform an XML resume into something gorgeous without writing too much programming logic. It's the reason so many technical book publishers use XML. Easy to transform content while also describing that content.

crdoconnor 12y ago
It is horrible for markup too. It is far, far, far too complex and far more verbose than it needs to be. These are the hallmarks of a bad language (or metalanguage). It is absurdly popular in bureaucratic environments. Bureaucrats adore its complex rules, ability to create arcane standards and illusion of openness. It's also good for job security. However, none of that bodes well for the rest of us. I have used XSLT and I am absolutely appalled that something like that can even exist. It's actually worse than XML. It is a turing complete language (this means that you can make it as complex as you like, and boy oh boy does THAT happen), but its readability is AWFUL. There is a reason we have other general purpose languages turing complete like python or javascript or even java and that is because, while they may have some warts, they have had a lot more thought put into them in order to help make them more consistent, better structured and readable than similarly committee-designed / thrown together languages like XSLT. I can use a normal programming language transform a JSON resume into something gorgeous and I GUARANTEE it will be lot easier to read and modify than your XSLT equivalent. Sorry to rain on your parade, but it's true.
- xienze 12y ago
  > It is horrible for markup too. It is far, far, far too complex and far more verbose than it needs to be. Oh stop. XML syntax is freaking simple. <tag>content</tag>, <tag><child>...</child>...</tag>, or <tag attribute="value" ...></tag>. Toss in namespaces for composing other formats _if need be_ (and you don't have to use them). And... you're done for 99.9% of any use case you can think of. You have to repeat yourself when you close a tag. Whoopdedoo. Any decent editor will close them for you anyway. I think the "XML sucks" crowd are conflating very complex XML _formats_ with XML _itself_ and deciding that XML is ridiculously complex and verbose because e.g., SOAP is complex and verbose. Just curious, do you hate HTML for similar reasons as well?
  - mindcrime 12y ago
    I have to agree. XML can be complicated, or can at least look complicated when using lots of namespaces and what-not, but for most purposes it's dead simple and about as easy to understand as anything else. Truth be told, I find XML easier to read than JSON in many cases. shrug
  - crdoconnor 12y ago
    You've forgotten: * DOCTYPE * Namespaces and namespace collision handling. * The likelihood that you will receive badly formed XML and be forced to parse it anyway. * The multiple different ways of escaping characters. * Language identification ...I could go on. Oh, and your parser has to handle ALL of this. It's no good assuming that "since the basics are fairly basic it doesn't matter". It doesn't matter only when you're generating XML, but somebody SOMEWHERE is going to have to consume it. Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser? This complexity is why. Just using it creates an increased attack surface for your internet facing API. >Just curious, do you hate HTML for similar reasons as well? I'm not its biggest fan, and I feel like it could have been done a lot better. However, A) there isn't much alternative so bitching about it it somewhat pointless and B) at least I never have parse it (want an exercise in frustration some time? try doing THAT...).
    - xienze 12y ago
      > You've forgotten: I was mentioning the "99.9%" use case of XML for e.g., a resume format. You don't have to specify DOCTYPEs, namespaces, etc. > The likelihood that you will receive badly formed XML and be forced to parse it anyway. You're supposed to fail on badly-formed XML! > Oh, and your parser has to handle ALL of this. So? I don't have to write an XML parser because there are numerous well-tested ones already written. I wouldn't write a JSON parser for the same reason. > Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser? First of all, you shouldn't speak in absolutes. You certainly could write a JSON parser that blows up for the same reasons. There's nothing inherent in JSON that makes it impossible to write a bad parser. > at least I never have parse it (want an exercise in frustration some time? try doing THAT...). For anything more than a trivial format you can automatically have the parser bind the content to a POJO (or your language's "plain old object" analogue).
- bphogan 12y ago
  Sorry to rain on yours, but XML isn't bad. The way people used it is bad. Just because you were forced to use bad schemas in enterprisey situations doesn't mean XML is bad. SOAP is not XML. Spring MVC is not XML. Those things use XML. Docbook's pretty easy to follow. That, in my opinion, is a great example of XML+XSLT. With XML I can do this: <experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience> It describes exactly what we're looking for in the same way as the JSON variant does. My editor will auto-close those tags the same way my editor will auto-close the closing curly braces in the JSON version. Of course, we could make it suck if we just go ahead and add all sorts of extra rules and hierarchy and turn it into a monstrosity. But I'd rather not.
  - crdoconnor 12y ago
    No, it IS bad and the complaint that 'people use it badly' is simply an excuse to cover for its deficiencies. In many ways, its deficiencies (which YAML/JSON do not have) are an incitement to use it badly, but that's far from the only problem with it. I am not complaining about being forced to use bad schemas in enterprisey situations, either. That is merely the icing on the cake of the badness that is XML. I am complaining simply because there is not one instance I have ever come across in my entire programming career (12 years now) where XML would have served me better than an alternative (assuming I had a choice). Zero. For example: >With XML I can do this: > ><experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience> Yes, you can, but so what? You can do that in YAML and JSON too. Furthermore, your YAML/JSON parser is 10x less complex, faster, less likely to have buffer overflow security issues and less likely to have memory leaks. Furthermore, while my app that consumes this markup will probably have to treat <experience><title>Manager<company>Veridian</experience> as valid, because consuming badly formed XML is standard and expected (your product manager will probably treat not parsing it as a bug), my app won't EVER have to treat invalid JSON as valid. >Of course, we could make it suck Yes, and there's a 90% chance somebody will. Whereas with JSON and YAML the chances of it being made to suck are far lower, because so many of the unnecessary avenues which are used to make XML suck are closed off in YAML.
- snarfy 12y ago
  I have to agree here. XSLT failed when they added <xsl:if>. Get your flow control out of my document format. That's what code is for. Adding <xsl:if> makes it code, horrible, horrible code.
  - bphogan 12y ago
    Oh, I don't know, it's kinda handy when you need it. How often have you wished for that in CSS?
  - dragonwriter 12y ago
    > XSLT failed when they added <xsl:if>. Get your flow control out of my document format. That's what code is for. XSLT isn't a document format, its by design a domain-specific programming language designed for use in transforming XML documents to other formats. > Adding <xsl:if> makes it code, horrible, horrible code. Its supposed to be code. Now, if you want to argue that its horrible code, that's another issue, but complaining that XSLT is code when that's the whole point of XSLT is, well, missing the point.

by bphogan 12y ago

crdoconnor 12y ago

It is horrible for markup too. It is far, far, far too complex and far more verbose than it needs to be. These are the hallmarks of a bad language (or metalanguage). It is absurdly popular in bureaucratic environments. Bureaucrats adore its complex rules, ability to create arcane standards and illusion of openness. It's also good for job security. However, none of that bodes well for the rest of us. I have used XSLT and I am absolutely appalled that something like that can even exist. It's actually worse than XML. It is a turing complete language (this means that you can make it as complex as you like, and boy oh boy does THAT happen), but its readability is AWFUL. There is a reason we have other general purpose languages turing complete like python or javascript or even java and that is because, while they may have some warts, they have had a lot more thought put into them in order to help make them more consistent, better structured and readable than similarly committee-designed / thrown together languages like XSLT. I can use a normal programming language transform a JSON resume into something gorgeous and I GUARANTEE it will be lot easier to read and modify than your XSLT equivalent. Sorry to rain on your parade, but it's true.

xienze 12y ago
> It is horrible for markup too. It is far, far, far too complex and far more verbose than it needs to be. Oh stop. XML syntax is freaking simple. <tag>content</tag>, <tag><child>...</child>...</tag>, or <tag attribute="value" ...></tag>. Toss in namespaces for composing other formats _if need be_ (and you don't have to use them). And... you're done for 99.9% of any use case you can think of. You have to repeat yourself when you close a tag. Whoopdedoo. Any decent editor will close them for you anyway. I think the "XML sucks" crowd are conflating very complex XML _formats_ with XML _itself_ and deciding that XML is ridiculously complex and verbose because e.g., SOAP is complex and verbose. Just curious, do you hate HTML for similar reasons as well?
- mindcrime 12y ago
  I have to agree. XML can be complicated, or can at least look complicated when using lots of namespaces and what-not, but for most purposes it's dead simple and about as easy to understand as anything else. Truth be told, I find XML easier to read than JSON in many cases. shrug
- crdoconnor 12y ago
  You've forgotten: * DOCTYPE * Namespaces and namespace collision handling. * The likelihood that you will receive badly formed XML and be forced to parse it anyway. * The multiple different ways of escaping characters. * Language identification ...I could go on. Oh, and your parser has to handle ALL of this. It's no good assuming that "since the basics are fairly basic it doesn't matter". It doesn't matter only when you're generating XML, but somebody SOMEWHERE is going to have to consume it. Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser? This complexity is why. Just using it creates an increased attack surface for your internet facing API. >Just curious, do you hate HTML for similar reasons as well? I'm not its biggest fan, and I feel like it could have been done a lot better. However, A) there isn't much alternative so bitching about it it somewhat pointless and B) at least I never have parse it (want an exercise in frustration some time? try doing THAT...).
  - xienze 12y ago
    > You've forgotten: I was mentioning the "99.9%" use case of XML for e.g., a resume format. You don't have to specify DOCTYPEs, namespaces, etc. > The likelihood that you will receive badly formed XML and be forced to parse it anyway. You're supposed to fail on badly-formed XML! > Oh, and your parser has to handle ALL of this. So? I don't have to write an XML parser because there are numerous well-tested ones already written. I wouldn't write a JSON parser for the same reason. > Wanna know why it's typically possible to blow up an XML parser with a memory leak or a buffer overflow but not a JSON parser? First of all, you shouldn't speak in absolutes. You certainly could write a JSON parser that blows up for the same reasons. There's nothing inherent in JSON that makes it impossible to write a bad parser. > at least I never have parse it (want an exercise in frustration some time? try doing THAT...). For anything more than a trivial format you can automatically have the parser bind the content to a POJO (or your language's "plain old object" analogue).
bphogan 12y ago
Sorry to rain on yours, but XML isn't bad. The way people used it is bad. Just because you were forced to use bad schemas in enterprisey situations doesn't mean XML is bad. SOAP is not XML. Spring MVC is not XML. Those things use XML. Docbook's pretty easy to follow. That, in my opinion, is a great example of XML+XSLT. With XML I can do this: <experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience> It describes exactly what we're looking for in the same way as the JSON variant does. My editor will auto-close those tags the same way my editor will auto-close the closing curly braces in the JSON version. Of course, we could make it suck if we just go ahead and add all sorts of extra rules and hierarchy and turn it into a monstrosity. But I'd rather not.
- crdoconnor 12y ago
  No, it IS bad and the complaint that 'people use it badly' is simply an excuse to cover for its deficiencies. In many ways, its deficiencies (which YAML/JSON do not have) are an incitement to use it badly, but that's far from the only problem with it. I am not complaining about being forced to use bad schemas in enterprisey situations, either. That is merely the icing on the cake of the badness that is XML. I am complaining simply because there is not one instance I have ever come across in my entire programming career (12 years now) where XML would have served me better than an alternative (assuming I had a choice). Zero. For example: >With XML I can do this: > ><experience> <title>Manager</title> <company>Veridian Dynamics</company> <description> Responsible for doing all manner of things. </description> </experience> Yes, you can, but so what? You can do that in YAML and JSON too. Furthermore, your YAML/JSON parser is 10x less complex, faster, less likely to have buffer overflow security issues and less likely to have memory leaks. Furthermore, while my app that consumes this markup will probably have to treat <experience><title>Manager<company>Veridian</experience> as valid, because consuming badly formed XML is standard and expected (your product manager will probably treat not parsing it as a bug), my app won't EVER have to treat invalid JSON as valid. >Of course, we could make it suck Yes, and there's a 90% chance somebody will. Whereas with JSON and YAML the chances of it being made to suck are far lower, because so many of the unnecessary avenues which are used to make XML suck are closed off in YAML.
snarfy 12y ago
I have to agree here. XSLT failed when they added <xsl:if>. Get your flow control out of my document format. That's what code is for. Adding <xsl:if> makes it code, horrible, horrible code.
- bphogan 12y ago
  Oh, I don't know, it's kinda handy when you need it. How often have you wished for that in CSS?
- dragonwriter 12y ago
  > XSLT failed when they added <xsl:if>. Get your flow control out of my document format. That's what code is for. XSLT isn't a document format, its by design a domain-specific programming language designed for use in transforming XML documents to other formats. > Adding <xsl:if> makes it code, horrible, horrible code. Its supposed to be code. Now, if you want to argue that its horrible code, that's another issue, but complaining that XSLT is code when that's the whole point of XSLT is, well, missing the point.