Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@a...] Sent: Friday, January 05, 2007 4:25 AM To: xml-dev@l... Subject: Re: 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@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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
