feedEntries tagged with “XML”
JSON vs XML wars are still going on, and they are becoming more amusing, I must say. The latest is from Sean McGrath arguing about the significance of mixed content in XML.
The discussion at Dare Obasanjo's blog, and the references to some other recent posts motivate me to look at some of the broader arguments being made. It is clear that processing JSON data using JavaScript is trivial, and that is what makes JSON a popular alternative over XML currently. All other advantages and disadvantages over XML are incidental. If we take out JavaScript from the picture, JSON is not a clear winner. Both JSON and XML take some effort to parse and process outside JavaScript.
Does validation mean that interface and implementation are tightly coupled, making the service hard to maintain? Mark Baker posted some more questions on validation yesterday. Validation does have merits in some cases, and the bigger challenge is designing extensible interfaces.
This post is in response to Mark Baker's post on Validation Considered Harmful. He is partly right about the harmfulness of validation in the specific use case discussed in his post, but I disagree with the generalization implied in his post. Whether validation is useful or not depends on the schema design, and document validation is not a sacred cow worth picking on.
This post is in response to Sameer Tyagi's article on using JAX-WS for RESTful web services posted at the Sun Developer Network. I find a few points stated in this article troubling if not inaccurate - (a) it presents REST in a limited scope thereby showing SOAP in better light, and (b) it misses some key differences between REST and SOAP based web services. Beyond this, the example cited in this article just shows why you SHOULD NOT use JAX-WS for REST style web services. In this post, I would like to discuss the whys behind the two statements I just made.
What is the right response format for XMLHttpRequest in Ajax applications? The answer is simple for most markup-oriented applications - use HTML. For data-oriented applications the choice is between XML and JSON. Until recently I did not pay much attention to the question of whether to use XML or JSON. I just presumed that the use case at hand will dictate the format. I had a chance to test this presumption recently. In this post, I would like to describe the criteria I used for comparing between XML and JSON, and my analysis.
Angle brackets or annotations? Is JAX-WS over-engineered or does it simplify web services development? I am disappointed with the points made by Richard Monson-Haefel and Jason Greene in their challenge and retractions against how complex or easy it is to use JAX-WS. Both their posts were provocative, but sidestep most of the requirements of complex web services. IMO, their positions are at the extreme ends.
In this post on What is XML? Jim Baldo asks a very interesting and important question. What does anyone mean by XML?
Last week, at BEA World 2005, I had a chance to hear David Orchard talk about WS-* standards [1], and future-proofing XML schemas and web services [2]. I also had a chance to discuss a few things. Both his sessions were quite informative and insightful, and brought out a few key points. I would like to share my thoughts here.
Several months ago, I blogged about versioning of web services. Between then and now, I realized that versioning of web services is a very nebulous topic, and that the problem of versioning could test the motivation of even the most committed web services architect. In this post, I would like to take the next step and discuss some possible ways of versioning web services. In this process, I would like to answer two questions:
Besides the technical issues involved with versioing of XML schemas, and the processing of versioned instance documents, there are a few situations that make it hard to implement versioning solutions.
Having spoken to a few folks at work on this topic, I would like to make a few more comments on versioning. See this and this for some background.
In my previous post, I discussed two approaches that I found useful for versioning XML schemas. The second approach in that post involved redefining all types from previous versions into later versions without actually importing those types. As this involves no type reuse, if you are using schema-driven code-generation tools like XmlBeans, you will notice that, each schema version leads to a different set of interfaces/classes.
XML versioning is a much talked about problem. Despite the volume of information available on XML and schema versioning, most people agree that this problem is hard with no single "silver-bullet" solution. In this post, I would like to discuss some possible solutions that can be implemented with data binding solutions such as XmlBeans. As always, this is work-in-progress, and I welcome any comments.
Managing change and versioning of web services can be hard. Although based on loose coupling and extensibility concepts, when it comes to change, web services are not far from older supposedly not-so-loosely coupled RPC-style technologies.
Most changes have good intentions - either they fix something broken, or try to enhance the service by adding new features. However, except in the most ideal cases, changes are disruptive. As David Bau explains in his "morning after" scenario, the need for compatibility can scuttle most plans for change. It is not always easy to foresee changes and future-proof the design, but eventually, we all get tasked to make changes.