>
> But it's mostly irrelevant at this stage; a historical warning about
> standards development. If you want to exchange data nowadays, the
> trend seems to be to use JSON, unless your processes are already
> using XML for other purposes.
Linked Data has some merits. The biggest question beyond that for me
is, who is to be in control of the format of the data? If it's the
application developer at the receiving end, use JSON. If the data is to
be vendor-neutral and have a long lifespan, consider XML.
The question that should be asked is apart from the web application developer what use case is really crying out to be sent JSON.
Why would an enterprise with applications in which the data's ultimate source and destination is a normalized Oracle or SQL Server want to receive or store any of that data in JSON.
Why would an information exchange application (govt or private sector) standardized on a contract specified in XML Schema (fpML, ACCORD, NIEM, MUREX) want to receive or store any of that data in JSON.
Why would an application with triple store end points want to receive data in JSON.
The burden of the impedance mismatch (real or imagined) the Dev is agitating to avoid is being transferred to the less vocal stakeholders. It just so happens that they are the people who either use or own the data but they end up being force fed something that suits the developer with a side helping of learn how to program an API for good measure.
It's a bit of a nonsense that the data needs of an application or enterprise are being determined on the basis of what is good for the devs and hence data is being trafficked in a format that has the ecosystem of an illiquid currency.
