11–20 of 46 posts
Dings XML for crappy commenting syntax then gives JSON a pass for not supporting comments at all. I love JSON, but it does have it's issues.
And here I thought everyone hated XML...
I don't hate XML, I just think it tends to be misused. I (still) think XML is fine for configuration files and things like markup of UI/UX components (See: Flex, WPF, Android layouts, etc). In this context, where you may be modelling the relationship between many parents with many children nested fairly deeply, I find XML much more readable and easy to edit and reason about than JSON. Where XML makes little sense is…
Dings XML for crappy commenting syntax then gives JSON a pass for not supporting comments at all. I love JSON, but it does have it's issues.
this is not a very good article, in all honesty. he doesn't like the syntax, but doesn't seem to consider that different technologies can be suited to different problems, or that he simply hasn't experienced the kind of uses where xml works well.
The solution I came up with was a program that transformed the documents by flattening them into a relatively small hierarchical structure that represented the volume/chapter/section headings of the book, and a flat list of elements that were small enough to parse quickly. I inserted ID and IDREF elements to link these two parts together, and created an external index of the file offsets and lengths of each element in the flattened list. That let me use simple file I/O to access any element by ID, pull it out of the larger file, and only then start the parsing engine.
It was like the article mentions: my XML file, together with the external index (in a simple Unix DBFile file) was a miniature NoSQL database of the textbook.
BTW, this predated the "NoSQL" label, and was developed after testing of Oracle and the XML databases of the day completely failed to meet performance and scalability requirements. My solution has an infinite capacity to scale; its performance is not impacted by the number of books in the system nor their size. The retrieval and display time of a single chapter or any subelement is a constant proportional only to the size of that chapter, and is not affected by the overall size of the collection. All of the other solutions we looked at got slower as the number of books increased and as the size of the books increased. (I mention this only to head-off any comments about reinventing the wheel.)
XML, being in the markup family tree, has a lot more history then simple json encoding ... measuring its usefulness on a corner case has always been well ... boring. I am glad people are using JSON to sling simple data across the web versus markup. Come back to me when you are using json to encode an entire document ... you might look at XML a bit differently. tl;dr use the right tool for the right job.
Yes, But I would claim that by being designed for many jobs in a sloppy way, XML became a terrible tool for all jobs. Json is a good replacement for XML in some of the application for which some folks foolishly targeted XML (I worked on a server back in the day that really did process five times the data 'cause of our use of XML for interchange - as was the new standard at the time , remember "XML everywhere!"?). Htm…
XML in its original role of extensible markup is thriving and completely successful ... as I previously mentioned, I am glad we are not slinging around angle brackets and happily use JSON instead.
I agree that XML was hijacked during its hype cycle to do a lot of jobs it should have never been intended to do ... AJAX (see the X) was a side effect of this, and we moved on to AJAJ ... evolution sometimes needs different routes to get out of local maxima.
Note also that there is a very long tail of XML vocabularies that you will never use or hear about that get extended and reflect their authors intents, w/o nary an agreement required between you (or I) to get real work done.
HTML5 though is where I have the problem (in terms of XML Failure)... baked in controlled vocabularies ... hmmm, what happens when your tag (or attribute) du jour doesn't pass muster with the WHATWG ?
I console myself by saying that both XML and HTML5 are part of the same markup family, just a short term family dispute for the time being; never bet against markup (or data for that matter) as they tend to stick around a lot longer then the programming languages that generated them.
Dings XML for crappy commenting syntax then gives JSON a pass for not supporting comments at all. I love JSON, but it does have it's issues.
JSON not having comments is a benefit when used for it's primary purpose: information exchange. JSON is not a great format for configuration files or static documents even though it's increasingly used for it.
the main arguments are about syntax. there's no mention of namespaces and schema are dismissed because the author didn't use them. no mention of tools for automated processing. this is not a very good article, in all honesty. he doesn't like the syntax, but doesn't seem to consider that different technologies can be suited to different problems, or that he simply hasn't experienced the kind of uses where xml works we…
Transformations, schema checking, xpath queries, well defined linking and embedding, a host of tools that support applications of XML on every platform, the list goes on and on. JSON has none of this, it's basically exactly what its name says it is ('JavaScript object notation') and not much more. It covers maybe 10% of what XML and all its related tools and standards are. The current trend seems to be that XML is 'old technology' and all the cool kids use JSON, and it bugs me. You can't possibly sincerely say JSON is 'just like XML but less verbose' unless you simply don't really know much about XML at all.
And here I thought everyone hated XML...
I don't hate XML, I just think it tends to be misused. I (still) think XML is fine for configuration files and things like markup of UI/UX components (See: Flex, WPF, Android layouts, etc). In this context, where you may be modelling the relationship between many parents with many children nested fairly deeply, I find XML much more readable and easy to edit and reason about than JSON. Where XML makes little sense is…
In fact, I think it's fair to say that WPF and all of Microsoft's config and resource file formats inherit their use of XML from mimicry of the Java ecosystem when C# and .NET were being developed as an alternative stack to Java. Android's inheritance is more direct, since it's based on the Java ecosystem. And as we all know, the crazy hype phase that XML went through was hand-in-hand with the crazy hype phase that Java went through. If Java hadn't happened, XML probably still would have as an improvement over SGML, but it probably would have remained the simple document markup language that it's pretty good for rather than becoming the "XML Everywhere" beast.
Earlier quoted context omitted.
Yes, But I would claim that by being designed for many jobs in a sloppy way, XML became a terrible tool for all jobs. Json is a good replacement for XML in some of the application for which some folks foolishly targeted XML (I worked on a server back in the day that really did process five times the data 'cause of our use of XML for interchange - as was the new standard at the time , remember "XML everywhere!"?). Htm…
'XML became terrible for all jobs' ... you do realize that there are literally hundreds of billions of xml encoded documents out there, happily doing what they are supposed to do ... not trolling; but lets put some of the comments in context for what they are. XML in its original role of extensible markup is thriving and completely successful ... as I previously mentioned, I am glad we are not slinging around angle b…