Simon, Right track? Not having explicit semantics? The popularity with programmers can't be denied but is that the measure for "right track?" Like spaghetti COBOL code, a lack of explicit semantics is a key to long term employment, but I don't see that as a good thing. (Not to single out JSON, the documentation protocols for Hadoop and family are based on C. Yeah, way to go.) Authoring angle-bang syntax isn't the difficulty in using XML, although it is rumored to be verbose. It's choosing and adhering to a consistent semantic that's hard. Hope you are at the start of a great week! Patrick On 06/25/2018 08:26 PM, Simon St.Laurent wrote: > On 6/25/2018 5:59 PM, Peter Flynn wrote: >>> My personal feeling is, that people would choose XML when they're >>> developing a big software instead of a tiny one. And when good >>> software engineering is important. >> If this is true, then the software industry is in a worse state than we >> imagined :-) > > I don't think this is about flawed software engineering. The JSON > folks seem to me to be largely on the right track. > > JSON had the advantage of arriving (technically, being abstracted from > JavaScript) after XML's trajectory had become clear. XML began as a > simplification process - XML a reduction of SGML, XSLT a reduction of > DSSSL, XLink a reduction of HyTime - but it didn't stay that way. > > XML showed the spectacular possibilities of text-based formats for > exchanging information, throwing communications doors open to people > well beyond the usual suspects of protocol design. That part was > amazing, and people suddenly realized the possibilities that had > quietly existed just outside of respectable core programming knowledge. > > Unfortunately, the XML community's response to all of this interest > was to sprout endless committees to build new tools to let XML do even > more of that. XML sprawled as it piled on schemas, graph notations, > query languages, and anything else we could come up with to be all > things to all people. > > Though further simplification had its fans in the core XML community, > I can't say it was a particularly respected position among the people > running the visible projects. "Extensible" apparently applied to the > core specs more than markup in practice. > > Programmers groaned under the complexity and the intrinsic mismatch of > markup structures and programming structures. Along came Douglas > Crockford with a ready-made solution! > > JSON's status as an extraction spared it the endless extensions, and > its source meant that it was a natural fit. It was data structures > for a programming language, and nothing more. (By happy coincidence > it was also effectively a subset of YAML, the one other project of its > kind to get traction with programmers.) > > JSON has - much more cautiously - evolved more formal specifications, > schema languages, and many varieties of tooling. (At least one of the > participants in that, Tim Bray, is familiar from XML.) JSON messages > and JSON-based APIs are sprawling across the Internet and beyond, but > the core set of knowledge needed to work with JSON has stayed manageable. > > Yes, there are at least two cases where XML is a better choice: > > * I wince when I see documents represented as JSON, especially if > anyone ever has to work on the JSON directly. Markdown and asciidoc > are better choices for those allergic to markup, even. Limited, yes, > but extremely useful. I see document parts as JSON constantly, in > APIs that would have been smarter just to send HTML fragments. > > * It is certainly possible to create systems that are complex enough > to need the tools of XML Schema and friends to present a complete > description of interchangeable data structures. Unfortunately, we tend > to forget that these projects are outliers, not the kinds of projects > that most developers build or even need to interact with at that level. > > XML started out as a sleek lifeboat escaping from SGML. Somehow we > kept bolting on more and more. While the results were pleasing to a > certain crowd, XML wound up desperately top-heavy, an easy target for > the lightweight JSON fleet. > > Sometimes you need a battleship. Most people don't. > > Thanks, > Simon > > > _______________________________________________________________________ > > 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@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php -- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau
Attachment:
signature.asc
Description: OpenPGP digital signature