Standardizing Alternate Encodings

By chance, this same conversation bubbled up over on the oBIX
list today. Participants in one of the Smart Grid standards committees who are particularly
interested in this issue might want to sign on to oBIX as well, at least as an
observer.  Note: I am not saying Brian’s proposal is the answer. I
am saying that the small device side of the conversation is being engaged in
such a way that interoperability with the larger economic conversations can be
reasonably handled.

 

tc

 

"A man should never be ashamed to own that he has been in
the wrong, which is but saying ... that he is wiser today than yesterday."
-- Jonathan Swift

 

  
  
Toby Considine

  
Chair, OASIS oBIX TC

  Facilities Technology Office

  University of North Carolina

  Chapel Hill, NC

  
  
  
  

  
  
  
Email: Toby.Considine@
  unc.edu

  Phone: (919)962-9073 

  
http://www.oasis-open.org 

  
blog: www.NewDaedalus.com

  
 

 

 

From: Frank, Brian
[mailto:] 

Sent: Tuesday, March 31, 2009 11:26 AM

To: 

Cc: 

Subject: [obix-xml] 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