XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] 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]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS