ql.io – a SQL-style way of mashing-up web APIs

The guys at ebay have released ql.io, which seems to be a way of using SQL-like queries to fetch and join data (typically in the form of JSON, it seems) from multiple web APIs to generate quick “mashups”.

See ql.io.

I can’t help thinking that there are a lot of hidden issues around API compatibility and conflicts, as well as the complexity of specifying increasingly tricky business processes, though. All these issues have been encountered in the XML workflow and process modelling world.

This certainly looks an interesting way to get started quickly with quite a broad class of mashup applications, though.

Freja – a JavaScript framework for in-broswer MVC applications

This looks really neat. A small JavaScript framework for setting up and running a single-page XML/XSLT application which fetches model data and view definitions from a server and combines them using JavaScript controllers. Once the data and views are loaded the application can run with no server latency, limited only by the ability of the browser to process XSLT and JavaScript.

Freja – CSScripting.

My personal preference would probably be for models in JSON rather than XML and a view template language a bit more developer friendly than XSLT, but this seems a good implementation nonetheless.

Martin Fowler dislikes rules engines. I’m not so sure

There’s no doubt that a generic rules engine can sometimes be a solution in search of a problem. The work to implement and manage both the rules and their interfaces with external systems can often completely dwarf any work which might be needed to implement the same behaviour in a regular programming language.

Martin Fowler has recently written about this problem in his “bliki”, and comes down in favour of always putting the effort in to work on a programming language solution alongside any exploration of a rules engine approach.

MF Bliki: RulesEngine

However, rather than seeing this as a reason to distrust the idea of rules engines as a whole, I prefer to see this is a problem with the implementation of traditional rules-engine technology. There is an argument, for example, that current fan favourite language Erlang is largely a rules engine.

The history or rules engine development is long, and many of the common conventions have a largely historical basis. The choice to represent rules in a text file represented as some lisp-based format (or a slightly more modern equivalent using XML), for example, is not really key to the concept of a rules engine. Likewise the heavyweight and single-threaded way that many rules engines operate is also mainly a historical implementation choice.

A light weight and efficient rules engine, well-integrated with the host language or environment is entirely possible, but despite several searches around the software universe I have found very few candidates, and none of the usual suspects, which work this way.

Maybe I ought to dust off my own implementation again ;)

Describing RESTful Applications

I have read a lot of faux-REST APIs recently, which are essentially just HTTP/XML or HTTP/JSON remote services, and still need a client to be pre-built with specialist knowledge of URI structure. “Proper” REST allows a server to change its URIs however and whenever it likes, with client applications seamlessly adapting to the change.

InfoQ has published an excellent article describing an approach to building fully self-describing REST interfaces.

InfoQ: Describing RESTful Applications

I still think more work is needed, though, particularly in the area of content types. The suggestion of application/blah.whatever+xml as per RFC 3023 is certainly better than an unadorned text/xml, but still does not provide the flexibility for client applications to sensibly handle new, yet similar, content types. In particular that proposal is limited to XML, with no equivalent for JSON or other data description formats.

Alternative approaches such as text/xml/blah/whatever might allow a more general support. In this example, transport and storage responsibilities might only care that it is essentially a textual format (something which is worryingly implicit in application/blah.whatever+xml), while parsing components might only care that it is text/xml, and so on. There is then the possibility for further information to be encoded in the content type. Consider a type such text/xml/link@href/whatever, which might indicate a textual format, parsable as XML, in which relationship URIs are indicated as a link element with an href attribute, and so on.

While compelling, such an approach could easily lead to fragility, though. Such a representation implies that the range of available content types is a strict single-inheritance tree ontology, with all the familiar problems
that entails.

Definitely an area for further research.

SMIL 3.0 Reaches Proposed Recommendation

SMIL is an interesting “sleeper” technology. A way of scripting the interaction and relationship between multimedia objects such as videos. I have seen some interesting Quicktime experiments based on SMIL, but so far it has remained inaccessible to casual web users and relatively difficult to use from familiar programming environments.

However, it seems that a new XML-based version is being proposed as a W3C standard, with the intention of driving adoption and support.

Ajaxian » SMIL 3.0 Reaches Proposed Recommendation

Never return Null Arrays – really?

Scott Selikoff recently posted that we should “never return null arrays”. I’m not sure I entirely agree. Both the tone of the article and the comments so far seem to be in agreement, but I am still not so sure.

I’ll skip the terminology issue for the moment, just note that an array in Java is different, in syntax, interface and implementation, from a Collection. Scott’s article seems to discuss Collections rather than arrays.

As far as I am concerned, there is a qualitative distinction between a Collection which exists, but is empty, and a collection which simply does not exist (i.e is null). I’ll grant that in many situations they should result in the same action or output; but not always.

Imagine parsing XML documents. Consider the following three cases:

  <result>
  </result>
  <result>
     <stuff/>
  </result>
  <result>
     <stuff>
       <item id="1"/>
       <item id="2"/>
     </stuff>
  </result>

I suggest that first and second cases are different. It’s relatively easy to imagine that some software should behave differently in the case where the “stuff” block is not present at all, and in the case where it is present, but empty. A simplistic example might be that in the second and third cases a “Stuff” heading is rendered on a web page, but not in the first one.

If that abstract example is not enough to convince, consider the more practical example of an “all you can eat” buffet restaurant (pause for a Homer Simpson “mmm … buffet“). The way many of these places work is that when you arrive you pay a flat fee and receive an empty plate. You may then take that plate to the food and fill it with whatever you like. If you do not have a plate, you have not paid, and so can neither physically nor contractually fill it with food.

In this example the plate represents the collection. The state of having no (null) plate is very different from having an (empty) plate. The restaurant staff would be wise to know the difference.

Just for fun, here’s some java to illustrate:

public class Diner {
  private Wallet wallet;
  private Collection plate;
 
  public Diner() {
    wallet = new Wallet();
  }
 
  public void pay(Cashier cashier) {
    Money fee = wallet.extract(cashier.getFee());
    this.plate = cashier.payForPlate(fee);
  }
 
  public void selectFoodItem(Buffet buffet, Object item) {
    if (buffet.contains(item)) {
      buffet.grab(item, plate);
    }
  }
}
public class Buffet {
  public boolean contains(Object item) {
    return true; // the ultimate buffet :)
  }
 
  public void grab(Object item, Collection plate) {
    if (null == plate) 
      throw new RestaurantException("This is not a soup kitchen! Pay first or hit the road");
    if (plate.size() > 10)
      System.out.println("I see you brought your big plate, Alan");
    plate.add(item);
  }
}

The bottom line is that while the Null Object pattern is a very useful pattern, it should not be used indiscriminately. Just like any pattern, really.

Never return Null Arrays! | Down Home Country Coding With Scott Selikoff and Friends

I look forward to more thought-provoking posts from Scott and Jeanne!

So You Say You Want to Kill XML….

Ted Neward has posted a long and detailed discussion of the potential merits and disadvantages of Google’s “protocol buffers” approach compared with XML as a way of offering rich remote APIs.

I learned a lot from this article, and I’m still digesting it, so no snap opinions this time …

Interoperability Happens – So You Say You Want to Kill XML….

And adding to the pot, InfoQ have also written about the same subject:

InfoQ: Google Introduces Binary Encoding Format: Protocol Buffers

XML: The Angle Bracket Tax

Jeff Atwood goes off on a rant about XML and a whole bunch of commenters chip-in. I particularly like “Ant makes me cry.” :)

Coding Horror: XML: The Angle Bracket Tax

Slight Improvement to Stringtree XML Parser

Someone just pointed out that the light-weight XML parser included in Stringtree did not handle explicit CDATA blocks. The version in SVN now has provisional support for this.

If you need a simple and fast parser for textual data, then this should be all you need. For XML documents containing opaque binary data in a CDATA block, this may not be ideal. Currently CDATA blocks are loaded as String objects, and this can lead to incorrect data for bytes which do not represent valid characters in the current character set.

I am currently planning for the next version of the Stringtree XMLReader to offer the option of extracting a CDATA block as an unprocessed byte array.