OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] use of JSON instead of XML


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!


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
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

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS