[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] Proposal for Alternate oBIX Encodings
|
I got a comment about the JSON stuff. My main occupation is
Javascript development. I think JSON is nice for quick private projects, but it
is not a professional technology. JSON is only simple if you take the JSON
object and evaluate it. That means you are executing arbitrary code that you
just downloaded somewhere from the net (note that there is a difference between
the Javascript code that I loaded from one trusted host and JSON objects that my
Javascript program may retrieve from arbitrary service providers). Therefore
people who are serious about JSON use JSON parsers instead of just executing
the code. JSON objects and XML are both requested with the XMLHTTP request from
the browser. In the response JSON is a pure text object that has to be parsed
(or executed) and XML is text and an already parsed DOM tree of the document. I have a class that translates an XML DOM tree into JSON like
object and vice versa. The code is some hundred lines – less than your
usual JSON parser. In a SOA landscape you quickly come to a point where you need
namespaces. There is no standard for this in JSON. JSON limits your scope in
other ways as well (there is for example no clear distinction between
properties and attributes). In my experience building automation information
has a relatively complex structure. Our XML would not be straightforward to
represent in JSON. JSON is a technological lock-in while XML keeps your data representation
open to anything. Building automation is an area with pretty high standards and
little room for errors and messing around. I don’t think JSON fits in
well into that market. Regards Thorsten From: Frank, Brian
[mailto:bfrank@tridium.com] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]