Looks fine to me. 90% of what SGML/XML was about was the need for a ubiquitous, schema-independent text format capable of handling annotated trees with named part, and so I don't see that JSON compromises the goal much, except of course for mixed content where the solution is HTML or XML in strings.All that has happened is that it turns out that XML's design assumption that 'terseness is of minimal importance' is a losing proposition -- look at markdown, JSON/YAML, SHACL, and the stagnation of XHTML and DSD on the other. (This is not 'simplicity' this is conciseness.)So does that mean that SGML was actually right? That you in order to have a unified data model you need to be largely syntax-independent (or at least that you need to be able simulate various natural shorthand syntaxes), you need to support multiple syntaxes? If you dont, you get multiplicity. And that you need to be able to extend the base syntax with your own delimiters to get a richer set of syntactic markers? And that syntax recognition needs to be able to tell the processor metadata to set machine representation and validation (e.g in SGML you can shortreference a delimiter to an entity, and that entity could include tags, such as a PI to say that the text us a date)?In the 1990s, when fingers were expensive, a DTD modeller once told me they had gotten their client's rich SGML markup down to one character per tag. Supposedly, offshore operations made the need for efficient markup disappear: but the rise of the web has meant that in fact it is back with a vengeance: developers want to avoid typing too. And they want dense information on their screens.So I see three possible alternative responses.1. Life is beautiful. Let's enjoy having a small number of standard specialized syntaxes. SGML paid a large tax for its flexibility in complexity.Furthermore, the notion that the correct way to convert from n to m formats is through a single unified pivot format or data model, n to 1 to m (=n+m rather than n*m transfitmations), has repeatedly failed in practise: the most important formats get well supported in the pivot and the less important formats need to shoehorn, and some abstractions are not compatible; instead there is some optimal fanout where you have a number of less ambitious intermediate formats or data models to reflect major families better. So from that POV, a small number of distinct syntaxes/dara models like markdown/xml/html/JSON makes good sense.2. SGML 2.0: arbitrary syntax switching. SGML was created so that the same toolchains could support a wide variety of existing syntaxes: a format may go out of fashion but because it is well described the data would not be lost. But 30 years ago there was not adequate theory to describe the necessary classes of grammars (indeed, markup languages have spurred developments in theory to cover the gaps), there was no Unicode or WWW, and programming languages were constrained (the story I heard was that SGML keywords are max 8 characters to support a limitation of an early parser written in FORTRAN.)If you look at the work the XPath people did to come up with a data model that copes with JSON as well as XML you can see the need for unified processing chains still exists. But really, I expect we are better with layered syntaxes rather than arbitrary syntax switching.3. Embrace and extend: universal lexical layer, combined language. Abstract out XML, JSON etc into a unified lexical layer to allow fast scanning, and allow islands of different notations in xml. And then support something like thst XMON idea I raised last week, to allow JSON inside start tags after attributes. Or arbitrary plug in notations.RegardsRickOn 18 May 2017 04:25, "Simon St.Laurent" <simonstl@simonstl.com> wrote:I guess this isn't a surprise, as I remember web folks complaining in 2013 about having to manage some of their pages in unexpected JSON, but:
https://github.com/brentsimmons/JSONFeed/blob/master/pages/v ersion/1.markdown
I can't say I expect this to sweep the world, as RSS is both entrenched and pretty quiet lately.
Enjoy,
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