JSON Beats XML, or Ajaj vs Ajax


Should the Ajax term be changed to Ajaj? Since Ajax stands for Asynchronous JavaScript and XML, but with more and more the web favoring JSON (especially in rich Ajax applications), should it now be called Ajaj and stand for Asynchronous JavaScript and JSON?

The reason that I bring this up is that James Clark one of the major contributors of XML is now saying that JSON is now the way of, at least, the "Cool" web. The post where James talks about this is called XML vs the Web.

Below is an excerpt from his post.

If other formats start to supplant XML, and they support these goals better than XML, I will be happy rather than worried.

From this perspective, my reaction to JSON is a combination of "Yay" and "Sigh".

It's "Yay", because for important use cases JSON is dramatically better than XML. In particular, JSON shines as a programming language-independent representation of typical programming language data structures. This is an incredibly important use case and it would be hard to overstate how appallingly bad XML is for this. The fundamental problem is the mismatch between programming language data structures and the XML element/attribute data model of elements. This leaves the developer with three choices, all unappetising:

* live with an inconvenient element/attribute representation of the data;
* descend into XML Schema hell in the company of your favourite data binding tool;
* write reams of code to convert the XML into a convenient data structure.

By contrast with JSON, especially with a dynamic programming language, you can get a reasonable in-memory representation just by calling a library function.

Norman argues that XML wasn't designed for this sort of thing. I don't think the history is quite as simple as that. There were many different individuals and organisations involved with XML 1.0, and they didn't all have the same vision for XML. The organisation that was perhaps most influential in terms of getting initial mainstream acceptance of XML was Microsoft, and Microsoft was certainly pushing XML as a representation for exactly this kind of data. Consider SOAP and XML Schema; a lot of the hype about XML and a lot of the specs built on top of XML for many years were focused on using XML for exactly this sort of thing.

You can read the full post here.

While I don't think that XML will ever totally go away (nor should it), I do think that in most Ajax applications that JSON makes more sense to use (with the biggest exception being if you just want to display the data). So go out there and start using Ajaj!

How to Make a Search Based on Google's Product Search

You may have seen the Google Product Search and may have thought that it would be useful to include a customized version of the search into a website or application. Unfortunately, you can't just create a custom search engine based on the Product Search using Google's custom search creator.

So, how would you incorporate the Product Search into an application? The answer is to use the Google Base API. The API allows for you to call a feed and if you use the [item type:products] option it will use the Product Search data.

The API allows you to receive the feed in Atom, RSS and JSON formats. Google has also made it very easy by making a feed URL builder (you can access the builder here).

So, if you want to make an application using the Products Search now you can.

WADL Draft Updated


The Web Application Description Language--"WSDL for REST"--draft has been updated by Marc Hadley. The namespace has been changed to "http://wadl.dev.java.net/2009/02" to reflect the new draft, and other minor improvements over the Novemeber 2006 version have been incorporated. New and notable:

  • The status attribute was moved from the representation element to the response element. The cardinality of the response element was changed from 0–1 to 0–many. The fault element was removed.
  • Allow parameters at top level and parameter references to prevent repetition when a parameter is used in multiple places.
  • A resource type element may now contain resource child elements.
  • Allow multiple resources elements within an application.

If you're a RESTafarian who still believes in contract-first web services design, don't miss it. You can view the new draft here.

XML Backlash?


Now in the fourth edition of version 1.0 or second edition of 1.1, XML has enjoyed a popularity matched by few other technologies. Introduced in 1998 as a more general-purpose (and extensible) markup language than HTML (and also derived from SGML), XML has spawned a host of other related technologies (XPath, XSL/XSLT, XQuery, XML Schema, Relax NG, etc.) as well as a plethora of XML-based dialect languages covering every conceivable purpose.

In the world of enterprise programming (most notably Java), XML extended its reach to become the data/configuration/metadata format of choice. At one point in time, any software framework that even had a vaguely enterprise-y smell to it relied on XML almost as a matter of course: J2EE (EJB, Servlet API, JSF, etc.), Struts, Spring, Tapestry, and the list goes on. When the ability to communicate via HTTP between browser requests was popularized in 2005 (famously by Jesse James Garrett), XML was so prevalent that it was simply assumed that this was the data serialization format of choice--hence the term AJAX (Asynchronous JavaScript and XML) or the "XmlHttpRequest" object. Use of XML was simply unquestioned.

Then something happened, or started to happen...In the last few years other technologies have begun to encroach in some of the areas where XML was once so dominant: annotations in Java (attributes in C#), JSON , Protocol Buffers, and even YAML. Dissatisfaction with XML is on the rise. Could it be that developers are realizing that XML is not good for everything? The evidence is growing:

  • Much of the motivation behind Google Guice was to create as a "pure java"--i.e., sans XML--implementation of a dependency injection framework. One of the creators of Guice, "Crazy" Bob Lee, has made no bones about his disdain for XML as a framework design tool.
  • Spring itself followed suite, introducing a pure-annotation approach to dependency injection (in addition to the XML-based approach) in Spring 2.5.
  • Wicket advertises itself as having a "refreshing lack of XML".
  • JSON's compactness and ease of serializing/deserializing to and from JavaScript has made it a very appealing alternative to use of XML, and has taken a big bite out of the X in AJAX.
  • Numerous official Java specifications (EJB 3.0, JPA, JSF 2.0, Servlet 3.0) are moving away from the use of XML metadata and towards Java annotations. This is really one of the largest pieces of damning evidence, as Java specifications were one of the major drivers behind the canonization of XML as a key enterprise technology.
  • Some people have even gone as far as to dedicate web sites explaining why XML sucks.

Of course, as one may point out, this could just be the "vocal minority" voicing objections while the quieter majority continue to use it--and indeed the use of XML and the development of XML-related technology shows no sign of really slowing down. But this trend does raise the legitimate question of whether or not XML has really over-reached its original purpose (and usefulness), and needs to be re-evaluated for some of the use cases to which it is currently being applied. So, now that XML is in the denouement of its hype cycle, it is a good candidate for a more honest evaluation of its strengths and weaknesses.

Let's start with the minuses...

Drawbacks of XML

  • Verbose: By its very nature as a markup language, XML contains considerable redundancy (i.e., <tag></tag>). While this suits the hierarchical structure of markup languages well, it can be a big drawback, especially when dealing with large amounts of data. This verbosity carries real consequences in terms of processing efficiency and network transmission overhead. Technologies like MTOM or XOP are really a hack to get around this problem.
  • Trees: The hierarchical tree structure of XML is a generally useful structure, but is not naturally suited to every problem domain. Some types of data are simply better suited to other data structures: lists, maps, etc. Unnecessary representation of this data as a tree carries some consequences in terms of processing efficiency and complexity.
  • Markup Language: XML is a markup language, not an imperative or functional language. And it is not good at faking either one. This seems to be a fundamental point missed by some fairly knowledgeable people. The otherwise well-designed BPEL is a case in point: right ideas, wrong technology. This doesn't mean that XML can't be used as a kind of "Poor Man's DSL", but being declarative is about as far as one should stretch a markup language.
  • Language Metadata: Though specifications like XML Schema brought a kind of type system to XML, this was a type system meant to be language agnostic. Historically speaking, however, it is common to see XML applied as a tool for language metadata, forcing the tedious and non-typesafe use of references to language types. This is the classic XML attribute class="com.example.Foo" seen in way too many Java enterprise frameworks. A real facility for language metadata (annotations in Java or attributes in C#) is a much better solution.

Nothing world-shaking here. Most developers having to type out XML documents have probably thought of these at some point in time. So what are the good points?

Advantages of XML

  • Platform and Language Neutral: Although other competing technologies can make the same claim, this is one of the big reasons for the rise in XML's popularity in the first place.
  • Great tools: There are a very rich set of tools for working with XML, which is certainly one of the reasons for its great popularity. This makes working with XML a much simpler choice, since in most languages the parser and other tools have already been written for you.
  • Readability: Some people may argue with this and provide good counter-examples (EJB deployment descriptor files come to mind), but in general 90+% of XML documents I've ever seen are fairly readable. This readability, however, certainly does not scale: larger, more complex XML documents tend to be fairly unreadable, but this is often more of a consequence of the misapplication of the technology.
  • Namespaces: Although using different namespaces in an XML document can have some unexpected surprises for the beginner, generally speaking namespaces are a pretty powerful feature of XML. They enable, among other things, ideas like "mashups"--i.e., XML documents being extended or combined with other XML documents (or content) in ways not necessarily foreseen by the providers of those documents (think Yahoo Pipes). Being able to avoid conflicts between different data sources is one of XML's great advantages over other technologies that do not support namespaces.
  • Validation: Built-in data validation is another one of XML's advantages. However one may feel about the widely-used standard, XML Schema, having the heavy lifting of this tedious functionality off-loaded from the author to the tools is truly a blessing.

Using simple math, it would seem that the advantages outweigh the disadvantages. But of course, it isn't that simple and the benefits vs. drawbacks have to be weighed on an individual basis. Most of the abuses of any given technology usually stem from the case that simple facts like this get overlooked or forgotten amidst the hype. In the worst cases, this kind of thinking results in elaborate specifications that are designed simply as workarounds to the limitations of the technology. The "right tool for the right job" is the caveat here, but the warning seems easily forgotten.

The popularity of XML is definitely here to stay and the technology is generally "good enough" for most purposes to which it has been applied. But I think that it is important, as with any technology, to apply some critical thinking before using it for a given purpose. If you find yourself in the middle of coding an elaborate workaround to a problem you are encountering (performance or otherwise), the question "Why am I doing this?" should be more than a passing thought. A little (un?)common sense goes a long way in building the right solution.

Web Services, Part 2: WSDL and WADL


Part 1 of this series talks about SOAP vs. REST. In this installment I'll discuss the reasons for defining the web service contract between client and server, the existing methods for doing it, and the important concepts of each.

Defining the Contract

An important part of any web service is the contract (or interface) which it defines between the service and any clients that might use it. This is important for a number of reasons: visualization with tools, interaction with other specifications (e.g., web service choreography), code generation, and enforcing a high-level agreement between the client and service provided (that still gives the service freedom to change the underlying implementation). Taken together, they give pretty compelling use cases for having web services contracts, although advocates of minimalism may disagree.

When IBM, Microsoft, and Ariba submitted WSDL 1.1 to the W3C in 2001 as a language for describing web services in conjunction with SOAP 1.1, HTTP POST and GET, and MIME, it quickly became a standard used by every SOAP toolkit. This happened in spite of the fact that it never progressed beyond being a W3C Note (which, according to W3C, is a document available for "discussion" and not officially endorsed by the W3C). In fact, though there is both a WSDL 1.1 and 1.2, WSDL 2.0 is the only version of the specification officially endorsed by the W3C.

With the rise in popularity of RESTful web services, there also became a need to describe contracts for these types of web services as well. Although WSDL 2.0 attempts to fill the gap by providing support for HTTP binding, another specification fills this need in an arguably better way: WADL , a specification developed at Sun by Marc Hadley. Though it has not been submitted to any official standards body (OASIS, W3C, etc.), WADL is promising because of its more comprehensive support for REST-style services.

Web Services, Part 1: SOAP vs. REST


Developers new to web services are often intimidated by parade of technologies and concepts required to understand it: REST, SOAP, WSDL, XML Schema, Relax NG, UDDI, MTOM, XOP, WS-I, WS-Security, WS-Addressing, WS-Policy, and a host of other WS-* specifications that seem to multiply like rabbits. Add to that the Java specifications, such as JAX-WS, JAX-RPC, SAAJ, etc. and the conceptual weight begins to become heavy indeed. In this series of articles I hope to shed some light on the dark corners of web services and help navigate the sea of alphabet soup (1). Along the way I'll also cover some tools for developing web services, and create a simple Web Service as an example. In this article I will give a high-level overview of both SOAP and REST.

Why XML is far superior to JSON


I've read an article titled Does XML have a future on the web?, and it does not surprise me, because the author himself is the creator of JSON. Naturally, he would love to promote his stuff. I would like to ignore him but would like to address his questions.

Lets see what he got.

"For data transfer applications, XML is losing ground to JSON because JSON is simply a better data transfer format".
I want to know how? Everyone in the world knows XML is more recognized and widely used and it is well supported by every one of the vendors in the web world (Editors, Application Servers, Parsers, Web Servers, Loaders etc.). JSON's role is what? Simply converting raw text in to a JavaScript object. And how is that a better data transfer format? Can I take the same raw text and use it else where? I don't think so.

I heard there are some frameworks available for JSLT (yeah you heard it right, JavaScript - SLT) available as open source, still I would challenge the performance about those frameworks. I haven't tried them myself, but you cannot beat the performance provided by the native browser XSLTs. I could reuse same XML data and apply different XSLTs to get different sets of transformed structures. You can't even think about this using JSON. And that to you can transform using XSLT's in milliseconds. With JavaScript JSON, you'll be lucky if you can get it in seconds.

Also, what about reusability? My server still can send the same XML and I could put a SOAP wrapper on top of that and I could expose it to web services. Now anybody can invoke that web service. Not necessarily only on the web side, it could be invoked by any server side programs as well. XML is the de-facto standard for Data integration projects, Data warehousing projects. More and more corporations are moving towards a SOA (Service oriented architecture) model and more and more applications have to use XML as the data transport mechanism.

JSON may be used by applications which are not enterprise level, only for applications which deal with less data, and have no need for extensibility. But for more scalability, more robustness, and more extensibility, XML is your best bet. XML has more support and that's what your boss would like to hear.

Syndicate content