[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
[Summary] It's too late to improve XML ... lessons learned?
- From: Roger L Costello <costello@mitre.org>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Fri, 31 Dec 2021 16:42:02 +0000
Hi Folks,
This has been a terrific discussion - thank you!
Below are a few highlights. /Roger
-----------------------------------------------------------------------
[Michael Kay] XML isn't unique in being difficult to change once it's solidly established. Try changing the voltage or frequency on the national electricity grid.
[Stephen Green] Like politicians, you don't find their problems till they get to power and by then it's too late.
[Simon St. Laurent] I think a large part of the world has effectively subset XML to the simplest well-formed structures they can get away with. I don't think most of XML's excessive complexities stem from XML 1.0. (A few do.) They mostly come from the over-enthusiastic follow-on projects.
[Marcus Reichardt] Non-core specs on top of XML, such as namespaces, is where it has gone wrong.
[Murata] Delaying the release of XML 1.0 might have made it more complicated since there were very many requests for minor extensions.
[Michael Kay] I think the security concerns over external parsed entities are probably one of the major factors that have led people to seek alternatives to XML. With XML we've learned that "adding features later" only works if all the popular implementations get updated; and there's no guarantee that will happen. As regards the whitespace issue, I suspect the problem is that the SGML and XML designers never really imagined how popular XML would become for pure data interchange applications, where it's natural to assume that whitespace (as a sibling of an element node) is insignificant, which in turn means that tools reformatting XML by adding indentation tend to assume that whitespace can be freely added and removed.
[Rick Jelliffe] I think the lesson is that a standard technology will ultimately die when its community fractures into groups who take a win/lose approach of cavalier veto-ing whatever they don't need: there is a Mexican standoff and stagnation. The question should never be "How do I get only what I want" but "How do we each get what we each want?"
[Peter Flynn] Browsers lost interest in XML long ago (actually they were never much interested anyway). Data exchange was introduced half-way through the genesis of XML, if I remember correctly, and may perhaps have seduced potential adopters more than was good for them. But it's mostly irrelevant at this stage; a historical warning about standards development. If you want to exchange data nowadays, the trend seems to be to use JSON, unless your processes are already using XML for other purposes.
[Liam Quin] The biggest question for me is, who is to be in control of the format of the data? If it's the application developer at the receiving end, use JSON. If the data is to be vendor-neutral and have a long lifespan, consider XML.
[Roger Costello] When creating a new standard, get it right in its first version because if the standard is a success you likely won't get a chance to improve it later on.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]