[Home] [By Thread] [By Date] [Recent Entries]
> 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). Excuse me-the value of XML Schema in the Business world can not be understated. Mark Crawford SAP Standards Strategist Platform Strategy Group Technology Strategy Team, Office of the CTO Mobile: (703) 485-5232 ----- Original Message ----- From: rjelliffe [mailto:rjelliffe@a...] Sent: Saturday, December 04, 2010 01:55 AM To: xml-dev@l... <xml-dev@l...> Subject: Technological panic (was RE: RE: James Clark: XML versus the Web) 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! _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |

Cart



