[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: JSON comes for RSS

  • From: Stephen Cameron <steve.cameron.62@gmail.com>
  • To: Rick Jelliffe <rjelliffe@allette.com.au>
  • Date: Thu, 18 May 2017 14:38:33 +1000

Re:  JSON comes for RSS
Was XML ever meant to be read in a text editor as SOP? Seems weird to me that .docx and .xslx are now commonly seen formats.

On Thu, May 18, 2017 at 2:21 PM, Rick Jelliffe <rjelliffe@allette.com.au> wrote:
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. 


On 18 May 2017 04:25, "Simon St.Laurent" <simonstl@s...> 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:


I can't say I expect this to sweep the world, as RSS is both entrenched and pretty quiet lately.




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

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.