[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Technological panic (was RE: RE: James Clark: XML versusthe We

  • From: rjelliffe <rjelliffe@allette.com.au>
  • To: <xml-dev@lists.xml.org>
  • Date: Sat, 04 Dec 2010 17:55:52 +1100

Technological panic (was RE:  RE: James Clark: XML versusthe We
 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!



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.