The single biggest tradeoff and architecture question you need to answer – do you want complexity in the data or in the usage.
I agree with it. You do not get a free lunch by using a "simpler" data format unless your domain of concern is relatively trivial.
Say you are going from a schemaful (relational or XML) persistent environment to JSON - typically that will be in a repository optimised for scalability at the expense of consistency. The need for the functionality embedded in the database layer, schemas, triggers, referential integrity rules etc doesn't suddenly disappear and so the payback for "simplicity" and schemalessness is that all that functionality is going to end up in application code.
Which brings up a seldom mentioned point. JSON is a developer centric format. Who other than a developer would want to encourage a state of affairs that requires more and more functionality to manifest as application code and this developer centricity operates at the expense of everybody else that needs to work with the data.
Devolving the choice for the transport mechanism for ephemeral data to developers is fine because other players are largely insulated from the effects of that decision. Hence they are free to prioritise and prefer a format that is impedance free at destination.
t is a completely different kettle of fish to devolve the decision over a persistence format to the preferences of the same community. They are not the only ones that need to work with the data, in fact they don't even own it and implementing some bastardized form of SQL in a DBMS isn't a solution to the problems it causes.
RickYes, the best format for persistent records is not at all clear.Regards
Whether XSD really has a viable place in that quadrant either is not clear too: perhaps for XML databases. But if JSON has removed the need for data binding tools that use XSD, then a lot of XSD's big use-cases disappear, it seems to me.On Fri, Feb 17, 2017 at 2:38 PM, Ihe Onwuka <ihe.onwuka@gmail.com> wrote:The way Rick sees it makes alot of sense to me (but I would find room for RDF in the picture), whereas I find some of the other comments bemusing.Why isn't there much of a corresponding debate between XML and RDF (or JSON and RDF)?Well XML vs JSON is an issue is because the JSON community see their ecosystem as replacing rather than co-existing alongside other ecosystems (XML in particular). The attitude is JSON and it's ecosystem is all you need. The ability to deploy XSLT/XQuery 3.0 (or JSONiq for that matter) is largely irrelevant, because your chances of being able to deploy any of them in a JSON shop are slim to zero.Given that, being neutral wrt the two formats would imply being perfectly comfortable discarding XML (ecosystem and all) and switching to a typical JSON ecosystem. If I were not comfortable advocating such then I wouldn't be expressing neutrality.On Thu, Feb 16, 2017 at 8:32 AM, Rick Jelliffe <rjelliffe@allette.com.au> wrote:RickStored | i.e. records: XML+XSD | XMLHere is kinda how I see it. How do others see it?| Fields | LiteratureEphemeral | i.e. messages: JSON | HTML
------------------------------------------------------------ --
------------------------------------------------------------ -- On Thu, Feb 16, 2017 at 11:00 PM, Costello, Roger L. <costello@mitre.org> wrote:Simon St. Laurent wrote:
Ø I think that none of the data-centric cases
Ø where this conversation tends to take place
Ø are even appropriate use cases for XML at
Ø this point.
That is a fascinating statement Simon!
Would you elaborate please? I’d like to understand more fully what you mean.
Isn’t XML necessarily about data, i.e., data-focused, data-centric?
What are the appropriate use cases for XML at this point in history?
/Roger