Re: [xml-dev] XML's place in the world

[Kurt Cagle <kurt.cagle@gmail.com>]

Rob,

No doubt you're right there, but I do not necessarily think that the client-side crowd is about the only driver for JSON; it's pretty much non-existent in server to server communications at the enterprise level. 

JSON has a natural advantage in a JavaScript world. XML doesn't primarily because the interfaces involved in working with XML on browsers are primitive and generally non-compatible between platforms - DOM in particular is an issue, but even trying to a simple XPath on most systems is painful, and no browser supports XSLT2 or XQuery natively.

The irony is that XQuery 1.1 is actually to a point where I think it could significantly challenge JavaScript in the browser in terms of capabilities. Unfortunately, at this stage it's unlikely to make its way into most browsers any time soon (though there's some interesting work being down there with XQIB). 

Kurt Cagle
Managing Editor
http://xmlToday.org

On Thu, Nov 12, 2009 at 10:21 AM, Robert Koberg <rob@koberg.com> wrote:

On Nov 12, 2009, at 10:03 AM, Kurt Cagle wrote:
>
> Something that I think it worth noting is that for all the volubility of the AJAX crowd, JSON messaging is no longer really gaining traction against XML messaging, and may actually be shrinking. Admittedly, I'm biased in this regard, but I think as AJAX itself matures and toolkits become more "enterprise hardened" (and as RESTful services become more dominant), the mismatch between XML and JSON at the business level is a fairly significant impedance barrier to pervasive adoption.

The client-side crowd is vastly more interested in JSON than XML. XML comes up because the client-side dev was forced to use. Rarely would it be the first choice of data exchange between the server(s) and client.

I see it trending to offering multiple options. I like the Jersey and JAXB for this reason. I used to think jaxb was too brittle, but lately have been appreciating all the time it saves with generating the source code to enabling easy rendering of different content types.

http://server.com/path/to/resource.xml
http://server.com/path/to/resource.json

can use the same class and method to handle the request with me providing the code like:

return Response.ok().entity(someBean).build();

That being said, I would really love a standards based way of knowing what conversion between XML and JSON structures would provide across all the tools that do that type of thing.

best,
-Rob