Re: [xml-dev] json v. xml

[sterling <sstouden@thelinks.com>]

Maybe the over and over again differences of opinion as to how
things should be done could be solved ?  Consider:

1) Produce a complete list of functionalities (a portal)
   1.a  independent of language or vendor
   1.b. indexing every possible function 
   1.c. user selects function options  
   1.d. portal sequences functions
   1.e. portal creates executables to accomplish user intention.

2) function separated into I/O interoperable API components
3) APIs provide inter connect for each functionality 
4) Standards are defined in results produced, not technical
   requirements needed to produce the defined result.
5) vendors produce I/O interconnections (API)
6) functions listed must comply with finished result standards.

Users blindly create on the fly aps from a GUI. 
 
1. users assemble desired functions 
2. GUI announces and assembles functions
   [with help and explainations to guide users].
3. vendors select functions they wish to support
   (instead of user learn the language), 
4. vendors create the API (even the APIs could
   be vendor specific )
 
Users pay by function selected depending on the 
vendor requirements or existing paid for licenses.

Basically a Web Interconnect -Portal (WI-P)
and a Server Interconnect- Portal (SI-P)
would need to be constructed.  

The software however written in whatever language need 
no longer conform to any standards, nor would it need to 
be turing complete or anything else. Instead 
standardized inter operability would allow all users to
implement standard results from selected functions.

vendors would write their functions to produce the 
result and users would select the functions knowing
the result it will produce.  All of the rest of the
stuff would be hidden. 

me 


 

On Fri, 5 Jan 2007, Rick Jelliffe wrote:

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