8 ms·

XML fever (2008)

37 points by wtbob 11y ago

PaulHoule 11y ago
"No connection between RDF and XML" is definitely not true. (1) RDF uses the XSD types for literals, and (2) you can turn an XML document very directly into an RDF graph with interconnected nodes. Once you have done that you can go to "plain" RDF with simple production rules instead of insanely complex XSLT. That is, 250 lines of XSLT goes down to 10 lines worth of rules.
georgeecollins 11y ago
I feel like there is a similar condition, JSON fever.
- netheril96 11y ago
  I am a JSON apologetic that uses JSON for all serialization except when performance is critical. I am all ears for why I am wrong on this.
  - kyberias 11y ago
    No-one said you're wrong. Maybe that's one of the symptoms of said fever. ;)
  - wtbob 11y ago
    JSON is the least-bad solution in the present day, but it's not a good format in itself. It's excessively verbose, overloads symbols and strings and cannot map general objects to values.
arethuza 11y ago
"one of the most troubling XML problems that is often experienced when encountering schemas generated from UML models" To be fair I think pretty much any kind of output generated from a UML model typically has serious problems (code, databases schemas, XSDs, documentation).
agentgt 11y ago
Now in 2015 we have XML prejudice and aversion where people trash XML as the worse possible format. As with many things it has its strength and weaknesses a couple of them being that a parser exists for almost all programming languages and the syntax of XML is probably the most widely understood (given so many people know HTML). And while XML is complicated there are far more complicated formats (YAML). What we have today is format creation fever. Particularly in configuration languages. Hucon, TOML, YAML, JSON, sort of JSON formats (HJSON or whatever it is).
- zdw 11y ago
  Requisite XKCD link: https://xkcd.com/927/ https://xkcd.com/927/ The problem with XML is that there are a lot of different programming models (streaming, pull, DOM), many schema and validation formats (DTD, XSD, RELAX NG), to the point that most people didn't care and just manually generated some monstrosity surrounded <>'s using printf. Personally, the way to get value out of using XML today is to find or make a schema in the most restrictive and expressive format possible that's supported by your development environment (RELAX NG or Schematron are the prime contenders), then use it as a safety belt every time you read or write data. The schema helps handle all the nastiness of parsing, which is the real enemy: https://www.usenix.org/system/files/login/articles/login_aug15_02_bratus.pdf https://www.usenix.org/system/files/login/articles/login_aug...
  - agentgt 11y ago
    I agree but XML the language with out namespaces or schemas is still useful. Schema like technology are surprisingly hard to implement and very similar to writing a type checker. Most human readable formats do not support any sort of validation and just now we are starting to see the newer formats try to come up with schema specifications (http://json-schema.org/ http://json-schema.org/). I think the problem with XML has little to do with the language but the organizing ivory tower organizations that got carried away with extending it... but at least those extensions/enhancement were extensions and not modifications of the language itself (ie new versions). An anecdotal observation is newer specifications for languages seem to follow a more open and transparent ala OSS philosophy (ie spec is on github).
rrmm 11y ago
I inherited an application from a person who was apparently taken with XML. The app's data and output was kept in his own home-brewed XML format with hand written output and parser functions. His understanding of XML was as follows: Put whatever you want between '<' '>'. It certainly beats reading the w3c docs. Needless to say, I rewrote the application from scratch.
- krylon 11y ago
  > His understanding of XML was as follows: Put whatever you want between '<' '>'. Well, in all fairness, somebody with that attitude would give any serialization/data format a bad name. While I am not a fan of XML, you cannot blame that one on it.
supahfly_remix 11y ago
XML can have a defined schema to validate data against. Does JSON have anything similarly defined as part of the language? It seems like an afterthought. Does anyone use it in practice?
- arethuza 11y ago
  JSON Schema seems to work pretty well - I've used it in Python applications: http://json-schema.org/ http://json-schema.org/ I don't think there are any fancy graphical editors as there are for XSDs - but that's probably not a bad thing as I suspect if things are getting so complex that a graphical editor makes sense then you've probably allowed things to get too complex anyway.
- MrBuddyCasino 11y ago
  I always felt XMLs killer feature is its editor support: auto-completion through XSDs and instant validation. Unless I get that in other formats, I frankly don't care a lot.
iamthepieman 11y ago
I spent several years working with the Marklogic[0] document database before NoSQL was cool and before I had even heard the term. It was incredibly freeing working with arbitrary XML documents and fragments. As a benefit we were able to transform data into HTML markup with a simple XSLT transformation. You could create multiple views on the same data by just adding some logic to your XSLT or creating a new XSLT Queries are(or were at least, it's been many years) built in Xquery which is a simple, functional language that I found much easier to grok than SQL. Since XML is just a tree and both XSLT and Xquery work on the trees quite well, advanced searching, sorting and relationship graphs came almost for free. I would gladly work with that stack, or something like it, again. http://www.marklogic.com/ http://www.marklogic.com/
- EiZei 11y ago
  > a simple XSLT transformation. You don't see those words together too often.
vinceguidry 11y ago
"XML is like violence. If it isn't solving your problems, then you aren't using enough of it."
ctstover 11y ago
I'm sure others who have been around longer remember other examples, but in my life I have never before or since witnessed a media blitz for a "technical" standard as the coming out party for XML in the '90s. Almost overnight the book shelves, magazines (yes those were both things back then), and even TV news proclaimed the dawn of the new age. A wave incoherent mass insanity swept the industry with the promise that this sometimes white space sensitive text data format with all the deliberate under and over specifications that are hallmark traits of design by committee was literally going to solve every problem in software engineering, enterprise IT, and of course investing in the dot com dumpster fire (pre first collapse). The emperor never had any clothes. Disk space, network capacity, cpu time, sanity, dignity - mattered not. No problem could not be solved better with XML. Dissension was heretical. Any one else remember that?
- dmichulke 11y ago
  To this date I feel frustrated when I have to deal with a few pages of XML that could easily be a few lines of json. Then again, enterprises love it, so I can't complain too often or loud. Still, I often refer to it as XMHell and if you speak it fast enough, only the truly wise will understand and acknowledge it with a smile and a nod.
  - conorgdaly 11y ago
    "a few pages of XML that could easily be a few lines of json" There is no sane way that you could represent "pages of XML" in "a few lines of JSON". Maybe the point you're trying to make is that you need just a handful of key:value pairs but whatever generates your config sees fit to do incredibly deep nesting...but that would be an issue with your application, not XML.
    - dmichulke 11y ago
      > There is no sane way that you could represent I think you're wrong, namely because of arrays. Can you tell me how you'd represent [1, 2, 3, 4] in xml? If you think this example is contrived, please compare the dependency sections of a clojure project.clj vs that of a Java pom.xml
jdnier 11y ago
If you're looking to describe document structure in a markup language, especially where mixed content is involved (think think running text, not database results), XML is great.

XML fever (2008)

37 points by wtbob 11y ago

"No connection between RDF and XML" is definitely not true. (1) RDF uses the XSD types for literals, and (2) you can turn an XML document very directly into an RDF graph with interconnected nodes. Once you have done that you can go to "plain" RDF with simple production rules instead of insanely complex XSLT. That is, 250 lines of XSLT goes down to 10 lines worth of rules.

georgeecollins 11y ago

I feel like there is a similar condition, JSON fever.

netheril96 11y ago
I am a JSON apologetic that uses JSON for all serialization except when performance is critical. I am all ears for why I am wrong on this.
- kyberias 11y ago
  No-one said you're wrong. Maybe that's one of the symptoms of said fever. ;)
- wtbob 11y ago
  JSON is the least-bad solution in the present day, but it's not a good format in itself. It's excessively verbose, overloads symbols and strings and cannot map general objects to values.

arethuza 11y ago

"one of the most troubling XML problems that is often experienced when encountering schemas generated from UML models" To be fair I think pretty much any kind of output generated from a UML model typically has serious problems (code, databases schemas, XSDs, documentation).

agentgt 11y ago

Now in 2015 we have XML prejudice and aversion where people trash XML as the worse possible format. As with many things it has its strength and weaknesses a couple of them being that a parser exists for almost all programming languages and the syntax of XML is probably the most widely understood (given so many people know HTML). And while XML is complicated there are far more complicated formats (YAML). What we have today is format creation fever. Particularly in configuration languages. Hucon, TOML, YAML, JSON, sort of JSON formats (HJSON or whatever it is).

zdw 11y ago
Requisite XKCD link: https://xkcd.com/927/ https://xkcd.com/927/ The problem with XML is that there are a lot of different programming models (streaming, pull, DOM), many schema and validation formats (DTD, XSD, RELAX NG), to the point that most people didn't care and just manually generated some monstrosity surrounded <>'s using printf. Personally, the way to get value out of using XML today is to find or make a schema in the most restrictive and expressive format possible that's supported by your development environment (RELAX NG or Schematron are the prime contenders), then use it as a safety belt every time you read or write data. The schema helps handle all the nastiness of parsing, which is the real enemy: https://www.usenix.org/system/files/login/articles/login_aug15_02_bratus.pdf https://www.usenix.org/system/files/login/articles/login_aug...
- agentgt 11y ago
  I agree but XML the language with out namespaces or schemas is still useful. Schema like technology are surprisingly hard to implement and very similar to writing a type checker. Most human readable formats do not support any sort of validation and just now we are starting to see the newer formats try to come up with schema specifications (http://json-schema.org/ http://json-schema.org/). I think the problem with XML has little to do with the language but the organizing ivory tower organizations that got carried away with extending it... but at least those extensions/enhancement were extensions and not modifications of the language itself (ie new versions). An anecdotal observation is newer specifications for languages seem to follow a more open and transparent ala OSS philosophy (ie spec is on github).

rrmm 11y ago

I inherited an application from a person who was apparently taken with XML. The app's data and output was kept in his own home-brewed XML format with hand written output and parser functions. His understanding of XML was as follows: Put whatever you want between '<' '>'. It certainly beats reading the w3c docs. Needless to say, I rewrote the application from scratch.

krylon 11y ago
> His understanding of XML was as follows: Put whatever you want between '<' '>'. Well, in all fairness, somebody with that attitude would give any serialization/data format a bad name. While I am not a fan of XML, you cannot blame that one on it.

supahfly_remix 11y ago

XML can have a defined schema to validate data against. Does JSON have anything similarly defined as part of the language? It seems like an afterthought. Does anyone use it in practice?

arethuza 11y ago
JSON Schema seems to work pretty well - I've used it in Python applications: http://json-schema.org/ http://json-schema.org/ I don't think there are any fancy graphical editors as there are for XSDs - but that's probably not a bad thing as I suspect if things are getting so complex that a graphical editor makes sense then you've probably allowed things to get too complex anyway.
MrBuddyCasino 11y ago
I always felt XMLs killer feature is its editor support: auto-completion through XSDs and instant validation. Unless I get that in other formats, I frankly don't care a lot.

iamthepieman 11y ago

I spent several years working with the Marklogic[0] document database before NoSQL was cool and before I had even heard the term. It was incredibly freeing working with arbitrary XML documents and fragments. As a benefit we were able to transform data into HTML markup with a simple XSLT transformation. You could create multiple views on the same data by just adding some logic to your XSLT or creating a new XSLT Queries are(or were at least, it's been many years) built in Xquery which is a simple, functional language that I found much easier to grok than SQL. Since XML is just a tree and both XSLT and Xquery work on the trees quite well, advanced searching, sorting and relationship graphs came almost for free. I would gladly work with that stack, or something like it, again. http://www.marklogic.com/ http://www.marklogic.com/

EiZei 11y ago
> a simple XSLT transformation. You don't see those words together too often.

vinceguidry 11y ago

"XML is like violence. If it isn't solving your problems, then you aren't using enough of it."

ctstover 11y ago

I'm sure others who have been around longer remember other examples, but in my life I have never before or since witnessed a media blitz for a "technical" standard as the coming out party for XML in the '90s. Almost overnight the book shelves, magazines (yes those were both things back then), and even TV news proclaimed the dawn of the new age. A wave incoherent mass insanity swept the industry with the promise that this sometimes white space sensitive text data format with all the deliberate under and over specifications that are hallmark traits of design by committee was literally going to solve every problem in software engineering, enterprise IT, and of course investing in the dot com dumpster fire (pre first collapse). The emperor never had any clothes. Disk space, network capacity, cpu time, sanity, dignity - mattered not. No problem could not be solved better with XML. Dissension was heretical. Any one else remember that?

dmichulke 11y ago
To this date I feel frustrated when I have to deal with a few pages of XML that could easily be a few lines of json. Then again, enterprises love it, so I can't complain too often or loud. Still, I often refer to it as XMHell and if you speak it fast enough, only the truly wise will understand and acknowledge it with a smile and a nod.
- conorgdaly 11y ago
  "a few pages of XML that could easily be a few lines of json" There is no sane way that you could represent "pages of XML" in "a few lines of JSON". Maybe the point you're trying to make is that you need just a handful of key:value pairs but whatever generates your config sees fit to do incredibly deep nesting...but that would be an issue with your application, not XML.
  - dmichulke 11y ago
    > There is no sane way that you could represent I think you're wrong, namely because of arrays. Can you tell me how you'd represent [1, 2, 3, 4] in xml? If you think this example is contrived, please compare the dependency sections of a clojure project.clj vs that of a Java pom.xml

jdnier 11y ago

If you're looking to describe document structure in a markup language, especially where mixed content is involved (think think running text, not database results), XML is great.