4 ms·

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 ... bo

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.

billysilly 14y ago
"Come back to me when you are using json to encode an entire document" How is that relevant to the article, which is about COS? In other words, what does COS lack what XML has?
- jimfuller 14y ago
  I could just as similarly ask why the author even mentions XML ?
- patrickg 14y ago
  * Infrastructure (schema support - DTD, Schema, RelaxNG; transformation - XSLT) * No obvious document format (What encoding are the strings? How to escape characters? * Only used to describe predefined object types (boolean, strings, arrays, dictionaries * Hard to ensure the integrity of the data without interpreting the data from the interpreter itself (no external validation)
  - rauar 14y ago
    You know this can be done on top when you have demand for this? I prefer a non-bloated protocol format over XML anytime. How often does the DTD not matter at all ? How often is the encoding fixed by convention ? ...
    - patrickg 14y ago
      I use schemas (in the form of RelaxNG most of the time) almost every time I deal with XML. Together with schematron you can make very complex lint-like scripts to verify your data. Actually I program in XML with a self created programming language (formulated in XML). This together with RelaxNG and a good XML makes it fun writing XML and absolutely (syntax-)error free.
joe_the_user 14y ago
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!"?). Html is a good tool for web documents (who would have thought?) but you're right, XML fills in for a lot of other document uses - XML is so far the best generalization that splits the difference between a word document and an HTML file. But I suspect the celebrate if someone could put forward a better such generalization because even in the realms where XML is the best tool available, it is a bad tool. Perhaps if more people admitted the awful attribute/value ambiguity problem that the article very intelligently calls-out, the use of XML would be less painful. If we called it "Inconsistently Structured Data Intermingling Format" ISDIF, the young developers would have some idea what they were getting into.
- jimfuller 14y ago
  '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 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.

billysilly 14y ago

"Come back to me when you are using json to encode an entire document" How is that relevant to the article, which is about COS? In other words, what does COS lack what XML has?

jimfuller 14y ago
I could just as similarly ask why the author even mentions XML ?
patrickg 14y ago
* Infrastructure (schema support - DTD, Schema, RelaxNG; transformation - XSLT) * No obvious document format (What encoding are the strings? How to escape characters? * Only used to describe predefined object types (boolean, strings, arrays, dictionaries * Hard to ensure the integrity of the data without interpreting the data from the interpreter itself (no external validation)
- rauar 14y ago
  You know this can be done on top when you have demand for this? I prefer a non-bloated protocol format over XML anytime. How often does the DTD not matter at all ? How often is the encoding fixed by convention ? ...
  - patrickg 14y ago
    I use schemas (in the form of RelaxNG most of the time) almost every time I deal with XML. Together with schematron you can make very complex lint-like scripts to verify your data. Actually I program in XML with a self created programming language (formulated in XML). This together with RelaxNG and a good XML makes it fun writing XML and absolutely (syntax-)error free.

joe_the_user 14y ago

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!"?). Html is a good tool for web documents (who would have thought?) but you're right, XML fills in for a lot of other document uses - XML is so far the best generalization that splits the difference between a word document and an HTML file. But I suspect the celebrate if someone could put forward a better such generalization because even in the realms where XML is the best tool available, it is a bad tool. Perhaps if more people admitted the awful attribute/value ambiguity problem that the article very intelligently calls-out, the use of XML would be less painful. If we called it "Inconsistently Structured Data Intermingling Format" ISDIF, the young developers would have some idea what they were getting into.

jimfuller 14y ago
'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 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.