Technological panic (was RE: [xml-dev] RE: James Clark: XML versusthe We

[rjelliffe <rjelliffe@allette.com.au>]

 Is it really a sign of deficiency in XML if JSON takes over jobs which 
 XML is less good at?

 XML has influenced so much: we have document interchange from our TV 
 remote controls, we have tree APIs to argue over, we have programming 
 languages with annotations, we have Perl using Unicode, we have SQL's 
 that cope with trees, we have XML syntax and simple XPath available 
 directly in Scala, the idea of transformations and pipelines are not 
 foreign to many programmers now, etc.

 In the early days of XML, we bemoaned the hype that was causing it to 
 be used where it was not a good fit (RDF, XML Schemas, etc). When 
 something is too successful and then loses adoption to something better, 
 why worry? That is the reason plurality is needed: it isn't a flaw in 
 XML or JSON that they cannot exactly substitute for each other. Indeed, 
 since XML will not evolve at W3C, it will only last as long as there are 
 no clearly better competitors in each different niche.

 I think it is a real mistake to see JSON versus XML in terms of 
 supposed simplicity versus supposed complexity. What is notable about 
 both was that they piggybacked on existing deployed technology 
 (SGML/HTML and JavaScript respectively). They both were easy to port to 
 multiple languages or platforms fast.  They both added value and life to 
 technologies that were moribund and disrespected (rigorous markup and 
 dynamic HTML respectively.) They were not the result of slogan-based 
 engineering efforts.



 Cheers
 Rick Jelliffe


 BTW If you look compare markup (XML) and C-syntax data languages (JSON, 
 IDL), I think there are three typical differences:

  * Markup languages often have named bracketing, eg <dog></dog>. Data 
 languages use anonymous matching braces; therefore the data syntaxes are 
 not good for reading deep structures; consequently they have developed 
 the idioms of having smaller files, and added concepts such as "objects" 
 to provide concepts to match these other files.

  * Markup languages often have schemas.

  * Markup languages often have mixed content.

 Earlier on, I suggested that XML could be extended by using JSON syntax 
 in its attributes. But data syntaxes or even programming languages could 
 be extended to allow named bracketing too:  for example

   for-each dog in pound {
       process-dog:
          send dog bones;
       :process-dog
      }

 which is pretty much available with labels in C now


   for (i=0, i< POUND-SIZE, i++) {
       {process-dog:}
          pound[i].give(bones);
       {end-process-dog:}
      }

 Of course, I don't think they will be extended in this or any way!