RE: [xml-dev] json v. xml

["Len Bullard" <cbullard@hiwaay.net>]

JSON is a wire-wheel for a small sports car.   Reinvention there is fine.

There are similar arguments going on in other lists such as calls for
simplifications of X3D.   The pattern is this:  as long as a system is
closed (say single platform or single application) it can be simple and it
rely on in-house/in-world/platform tools.   Examples of that are
historically VMS, Wysiwyg/Macintosh, SecondLife and so on.   As soon as it
has to operate cross-platform in an open system, it will begin to become
complex as controls emerge to coordinate and filter multiple incompatible
requirements from the different application genre.  In the case of X3D, it
is the VR pundits vs the visualization pundits, and the script kiddies vs
the Java programmers.  (Just to be ornery, I much prefer the curly syntax
over the XML encoding when it comes to graphics.  PFE is kinder to curly.)  

It's a force model with multiple domains and attractors.   One ends up with
a gnarly looking space that has some flat broad spots in them.  All of the
people living in those spots keep telling the people living on the peaks
that they can flatten their part of the space and live in the flatland with
them and everyone will enjoy the exact same happiness.  The people on the
peaks refuse to come down because they like the longer view and don't mind
the loneliness because they are happier.

And so it will go.

JSON vs XML is not a technical debate.  It is a political debate.  So was
SGML vs WYSIWYG.   As the WYSIWYGERs attempted to put hypermedia features in
their systems, they began to adopt the techniques of the SGML 'losers' and
soon they had to reinvent SGML and here we are today.  As the SGMLers
attempted to become WYSIWYG, they build baroque toolkits that took rooms
full of people to manage and high-paid consultants to configure.

No, I don't expect SGML to be resurrected.  Too many luminaries might have
to admit they were wrong or that their religions of simplification are
near-sighted.  What I expect is to see this same debate repeated endlessly
at varying intervals for the rest of our careers and beyond.

It isn't the technology: it is the nature of information systems.  (... 'in
the stars...').

len

-----Original Message-----
From: Rick Jelliffe [mailto:rjelliffe@allette.com.au] 
Sent: Friday, January 05, 2007 4:25 AM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] json v. xml

Michael Champion wrote:
> I'm not sure it's
> a comforting thought to know that this could all be done the SGML way,
given
> that SGML was not exactly a resounding success outside a very small
> community. 
>   
Oh, your comfort was my most fondest concern, be assured :-)  But I'm 
not recommending a syntax or meta-syntax or data model or 
meta-data-model, let alone SGML (though certainly SGML is already 
modularized in IS8879, so it would be completely possible to redefine it 
as a set of transformations that ultimately generate XML or JSON, 
cleaning up a few things on the way and becoming more expressive along 
the way.)

There an SGML angle to it though. Non-dinosaurs may be surprised to 
learn that SGML's earliest, near-fatal challenger was not formats, but 
WYSIWYG. Old word processors (troff, Word Perfect, TeX, etc) all allowed 
you to play with tags; even the editors with presentation preview modes 
allowed you to edit the tags. Then WYSIWYG came along (with bastardized 
version of Ben Schneiderman's "direct manipulation" ideas) and the push 
was on for hiding tags both on-screen and in binary data formats, and 
against batch processing and transformation. SGML fitted into the UNIX 
pipes world that, while it never went away, was not the kind of 
mom-and-pop technology that soaked up all the capital and market share.

Apple, Adobe, MS, Corel, and all the software houses spent hundreds of 
millions of marketing dollars to push the glamour of WYSIWYG. Concepts 
of repurposing, semantic markup, hypertext links between documents, 
schema checking, document construction from components, let alone 
archiving or application-neutrality, were abandoned.  The "failure" of 
SGML is the "failure" of Vi over PageMaker. 

Failure is a matter of expectation. Is the Wiki format a failed 
technology? From the POV of sales, I am sure it it; from the POV of 
numbers using it, compared to Office or OpenOffice, I am sure it is; 
from the POV of its ability to be useful in creating Wikipedia-like 
things, it is obviously a roaring success (and Office and OpenOffice are 
failures).

So what is the angle? That a good idea ultimately wins through, despite 
counter-marketing, but only when the technological conditions are right. 
JSON could be in the same position.

In 1985, the question "Do different data formats need some underlying 
way to unify them" had an answer "yes", responding to the technology of 
the time (and lo SGML was born). In 1996, the question was answered "no" 
(and  XML was born).  In 2007, the question is getting asked again, and 
it may well have a different answer.  But, in the mid-80s, parsing 
theory was relatively widely taught, and systems like UNIX reflected it; 
by the mid-90s, parsing theory was not well-known, and systems like Macs 
and PCs reflected that; now in the 00s, I don't see any great resurgence 
in knowledge of parsing that would make the old SGML approach 
particularly congenial for users, even though perhaps more people are 
getting an introduction through XSD grammars and XSD regex to some 
concepts.

> Some sort of underlying
> unification principle, whether it be grammar-based or datamodel-based,
would
> seem useful to make their lives easier.   
>   
Here's a unification principle behind XML, JSON and Fast XML: don't 
re-invent the wheel.

Cheers
Rick Jelliffe

_______________________________________________________________________

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