4 ms·

Was XML Flawed from the Start? (2005)

9 points by draegtun 13y ago

pan69 13y ago
XML works very well as a serialization format. Especially when you apply schemas that are able to validate your XML structure. I agree, typing XML can be cumbersome but so can JSON (which can be quite nightmarish in larger blobs and which doesn't allow comments).
sven-n 13y ago
I guess the author didn't get the purpose of XML. It doesn't have the goal to use the least amount of metadata/tags as possible. If you need that, just compress it. Whatever, XML offers a wide range of tools, such as: - Data in XML can be transformed into almost any other format using XSLT. - It can be validated using XSD. - It can be searched using XPath. This makes it a perfect data exchange format.
- chinpokomon 13y ago
  Well formed and validated, two distinct concepts. Although it is sometimes deemed a negative, having attributes as well as nodes can offer subtleties that are unmatched in other data exchange formats. While I appreciate the usefulness of JSON, XML and its siblings XPath, XSLT, etc. have their own strengths but taking advantage of them is requires thinking differently.
- andrewflnr 13y ago
  Perfect? Really? There's no possible better way to achieve those goals? I've used XSLT; it's nasty.
  - sven-n 13y ago
    Well, I don't say there are not better ways, but I don't know any. I've used XSLT a lot. It requires different thinking, if you are used to procedural programming. If you deeply understand how it works, it's pretty straightforward.
    - andrewflnr 13y ago
      The concepts are straight-forward, but the syntax is absurd. I really liked it at first because it's functionally oriented, which is exactly what you want for transforming data. But it's so, so verbose because it's still trying to be markup instead of a programming language.
      - chinpokomon 13y ago
        You nailed it. XSLT is not a programming language, it is a data transformation language. Furthermore, it is a data transformation language written as a valid and well formed XML document. I was recently involved in an exercise to create a JavaScript runtime environment running in Java, and wrote JavaScript scripts to process JSON payloads that transformed them into a set of instructions that would change network switch configurations. The process that kicked off the transformations initially generated XML payloads, but it had been modified to generate JSON for the exercise... or more accurately that is what it would do, but we were in the POC phase. The difficulty in using JSON was that the payload wasn't flat but represented a system of woven objects, as was true of the original XML payload. The XSLT transformer while cumbersome to write was able to transform the payload using backtracking XPath references that was significantly more difficult to articulate when using JavaScript. In the end my POC method worked and it was easier for someone with a procedural programming mindset to read and write, but it lost some of the nuance of the XSLT method. Use the right tool for the job. I personally thought the best approach would have been a combination. Use a lighter weight XSLT to transform the objects into a more manageable payload and then use the JavaScript to handle the last mile tasks it was better suited to do. It was an interesting exercise and maybe I'll be able to leverage what I learned on a future project.
        andrewflnr 13y ago
        What do you mean, the original XML payload wasn't flat? At first glance XML is just as inherently flat as JSON (being a text string), but I guess there's some internal referencing semantics for XML documents? What did you really lose moving away from XSLT? Anyway, I think I'd rather have a nice programming language that's also well-suited to data transformation. I'd ditch XML for something more elegent and flexible and have a transformation language to match. That's my dream, anyway.
Turing_Machine 13y ago
Much discussion of similar issues here: http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions

9 points by draegtun 13y ago

pan69 13y ago

XML works very well as a serialization format. Especially when you apply schemas that are able to validate your XML structure. I agree, typing XML can be cumbersome but so can JSON (which can be quite nightmarish in larger blobs and which doesn't allow comments).

sven-n 13y ago

I guess the author didn't get the purpose of XML. It doesn't have the goal to use the least amount of metadata/tags as possible. If you need that, just compress it. Whatever, XML offers a wide range of tools, such as: - Data in XML can be transformed into almost any other format using XSLT. - It can be validated using XSD. - It can be searched using XPath. This makes it a perfect data exchange format.

chinpokomon 13y ago
Well formed and validated, two distinct concepts. Although it is sometimes deemed a negative, having attributes as well as nodes can offer subtleties that are unmatched in other data exchange formats. While I appreciate the usefulness of JSON, XML and its siblings XPath, XSLT, etc. have their own strengths but taking advantage of them is requires thinking differently.
andrewflnr 13y ago
Perfect? Really? There's no possible better way to achieve those goals? I've used XSLT; it's nasty.
- sven-n 13y ago
  Well, I don't say there are not better ways, but I don't know any. I've used XSLT a lot. It requires different thinking, if you are used to procedural programming. If you deeply understand how it works, it's pretty straightforward.
  - andrewflnr 13y ago
    The concepts are straight-forward, but the syntax is absurd. I really liked it at first because it's functionally oriented, which is exactly what you want for transforming data. But it's so, so verbose because it's still trying to be markup instead of a programming language.
    - chinpokomon 13y ago
      You nailed it. XSLT is not a programming language, it is a data transformation language. Furthermore, it is a data transformation language written as a valid and well formed XML document. I was recently involved in an exercise to create a JavaScript runtime environment running in Java, and wrote JavaScript scripts to process JSON payloads that transformed them into a set of instructions that would change network switch configurations. The process that kicked off the transformations initially generated XML payloads, but it had been modified to generate JSON for the exercise... or more accurately that is what it would do, but we were in the POC phase. The difficulty in using JSON was that the payload wasn't flat but represented a system of woven objects, as was true of the original XML payload. The XSLT transformer while cumbersome to write was able to transform the payload using backtracking XPath references that was significantly more difficult to articulate when using JavaScript. In the end my POC method worked and it was easier for someone with a procedural programming mindset to read and write, but it lost some of the nuance of the XSLT method. Use the right tool for the job. I personally thought the best approach would have been a combination. Use a lighter weight XSLT to transform the objects into a more manageable payload and then use the JavaScript to handle the last mile tasks it was better suited to do. It was an interesting exercise and maybe I'll be able to leverage what I learned on a future project.
      - andrewflnr 13y ago
        What do you mean, the original XML payload wasn't flat? At first glance XML is just as inherently flat as JSON (being a text string), but I guess there's some internal referencing semantics for XML documents? What did you really lose moving away from XSLT? Anyway, I think I'd rather have a nice programming language that's also well-suited to data transformation. I'd ditch XML for something more elegent and flexible and have a transformation language to match. That's my dream, anyway.

Turing_Machine 13y ago

Much discussion of similar issues here: http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions