Proposal for Alternate oBIX Encodings

Today oBIX defines an abstract object model with a single encoding based on XML. But the original vision behind oBIX was that multiple encodings could be defined all sharing the same interoperable object model. I would like to propose adding two alternate encodings of the oBIX object model to the 1.1 draft specification: JSON and Binary.

One of the things we are starting to see is many people are using oBIX as an AJAX data feed to their browser. In this use case, it is preferable to deliver the oBIX information directly in a JSON format rather than requiring JavaScript to parse the XML into a usable format.

Why a binary oBIX encoding? This requirement takes a little more background discussion. One of the technologies I have been deeply involved in is 6LoWPAN which is an RFC specifying how to run IPv6 over 802.15.4 wireless networks. I firmly believe that 6LoWPAN has the potential to unleash the Pervasive Internet by adding billions of new nodes to the Internet. But putting these devices onto the Internet is just the first step. The next step is to put them onto the Web so that they can be wired into humanities existing information infrastructure. Due to their resource and power constraints, 6LoWPAN devices cannot fully run HTTP or mange XML payloads. To the solve the HTTP problem, I am working on an RFC to run a compressed version of HTTP over 6LoWPAN. On the payload side, oBIX fits perfectly for defining a RESTful information model. But we need a compact encoding which can work with the small packet sizes required for 802.15.4 networks. I have some good ideas on how to achieve this without loosing any of oBIX’s modeling capability.

Clients would perform negotiation with servers for their preferred encoding using the Accept header (standard HTTP content negotiation).

Comments?

I would suggest we try to setup a teleconference next week (Mon or Tue preferably) to discuss this strategy.

Brian

obix-xml message