[Home] [By Thread] [By Date] [Recent Entries]

  • From: Patrick Durusau <patrick@d...>
  • To: xml-dev@l...
  • Date: Mon, 25 Jun 2018 21:02:46 -0400

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

-- 
Patrick Durusau
patrick@d...
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]


Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member