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

Re: Potential Risks of Migration from XML to JSON

  • From: "Liam R. E. Quin" <liam@w3.org>
  • To: Evan J <maps.this.address@gmail.com>, xml-dev@l...
  • Date: Fri, 14 Oct 2016 13:29:36 -0400

Re:  Potential Risks of Migration from XML to JSON
On Fri, 2016-10-14 at 04:44 -0400, Evan J wrote:
> I wanted to know about the possible risks that one might encounter
> while
> deciding to migrate the messaging format from XML to JSON in a data
> exchange environment.

Michael and Ihe have given really good high level answers

> Factors such as: complexity of data structures, validation
> requirements,
> security, etc. How would a system architect go about such analysis?

Data structures should be as complex as your needs; validation
requirements come out of the needs of QA, testing, and the
implementationof trust boundaries.

If (as is common) the data, whether XML or JSON, is coming over a
network, you need to be especially careful to assume that it might have
been tampered with maliciously. Just as XML system can be vulnerable to
CDATA injection attacks, badly-implemented JSON parsers may have
security weaknesses, of which the most common (alas) is still that they
execute arbitrary JavaScript ofter the end of the JSON structure,
and/or embedded expressions. Systems that use e.g. jQuery's JSON parser
don't suffer from this but are slower and use more memory.

This is a problem for JSON because the data is read in a programming,
rather than a data, context: a JSON document is really a serialized
JavaScript object. Outside of JavaScript the parsers are less likely to
use eval() to load the objects and hence less likely to be vulnerable.

The biggest long-term issue is that JSON culture puts the application
developr in charge of the information representation, which is fine if
it's a config file for an application and not so good if it's a Swahili
dictionary being transcribed for research purposes... as long term
maintenance and data reuse then dominate the decision.

After that, you need (as others have said) to look at producers and
consumers. If your current system is perceived as being too complex,
throwing it away and rebuilding might or might not be wise. Developers
tend to prefer to do that because it's more fun, but you also have to
look at the whole system. If the perception is that it's too slow,
moving to JSON may well make it slower.

The best book I've seen on this is "The Rhetorical Nature of XML",
except that only the alternate chapters are really really good, being
interspersed with more technical introductions about XML that are...
not so good.

Liam

-- 
Liam R. E. Quin <liam@w3.org>
The World Wide Web Consortium (W3C)


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