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

Re: Was OOXML's problem that it should have used JSON notXML?

  • From: Hans-Juergen Rennau <hrennau@yahoo.de>
  • To: xml-dev@lists.xml.org, Rick Jelliffe <rjelliffe@a...>
  • Date: Tue, 23 Jan 2018 08:10:43 +0000 (UTC)

Re:  Was OOXML's problem that it should have used JSON notXML?
Very interesting thought. At first, I was at a loss what you meant - in my opinion, XML technology is without serious competitor concerning the art of addressing information, and, by implication, the disciplines of navigation, extraction, aggregation, transformation. So why should something be "really better to do in JSON"? But then I (hopefully) understood your point: if the data should be viewed and used as a dump and nothing else - something exported for the sake of later being imported - completely different aspects emerge, and XML can become a bad choice. Behind this looms a very general question: WHERE DOES INFORMATION LIVE? (Here: only in a running MS Office program?) If you start to regard an OOXML resource as a place containing information in its own right, information to use (e.g. for analysis and reporting) and perhaps modify - the perspective changes, and the choice of XML appears in a different light. The emancipation of information, seeing it alive outside of the context of a running program designed for its use, is at odds with the developer's habitual perception.

With kind regards,
Hans-Juergen


Am Dienstag, 23. Januar 2018, 04:59:06 MEZ hat Rick Jelliffe <rjelliffe@allette.com.au> Folgendes geschrieben:


Here's a thought.  

OOXML (Office Open XML) is criticized for being like a dump of MS Office's binary format: it is not altogether unfair because the aim was to completely represent the native format and much of that was simply not "semantic" let alone elegant.  

But it meant that some technical at people freaked out when they saw it.  Not just because there was no SGML-ish mixed content or tree structure, or because MS clearly did not have adequate internal documentation or documentation QA for the most mission-critical software of businesses around the world [[what is ISO but an organization to facilitate QA of technical documentation?]], but also because it had such a severe reliance on chains of links and markup structures that were alien to the HTML kids.  (I will leave the ideological aspects out here.)

I wonder whether an objective cause to the subjective antagonism people felt towards it can be attributed to another factor:  they intuited that to some extent OOXML was trying to do in XML what really would be better to do in JSON?   I.e. moving around a big data structure.  

(And I certainly don't want to exclude the possibility that some parts would be better in XML and others in JSON, i.e. a JSON-in-XML-in-ZIP approach.)

Regards
Rick


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


PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
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.