XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Interesting XML ideas in oBIX

I work in that backwater of the software industry known as "embedded
software".  Curiously, without much fanfare, there is this phenomena
occurring where virtually every device with a microprocessor is getting
jacked into the Internet one way another.  For decades these devices
have spoken obscure protocols that most of you have probably never heard
of (and be glad you haven't).  But now that these devices are finding
their way onto the Internet, there has been a push to standardize
communication with embedded devices using all the current buzzwords like
XML and "Web Services".

So doing my part to foist yet another spec onto the world, we recently
just finished public review of an OASIS spec called oBIX to tackle some
of these problems.  There are some interesting ideas in oBIX which don't
seem to generate much discussion which I thought I would share:
   - Reflection of primitive types
   - Typing through prototype inheritance
   - Typing through ad-hoc "tagging"
   - Using REST to create a "web" of machine documents 

Every programming language I am aware of contains a basic set of
primitives used as fundamental building blocks: booleans, ints, floats,
enums, strings, etc.  The ability to reflect this information from an
XML document may seem trite, but it really does help make sense of data
encoded in XML.  Knowing that a leaf of a document should be an integer
versus arbitrary text helps down stream of the document in all sorts of
nifty ways - such as auto-generating user interfaces or plugging into
language constructs a programmer can use (I think this is one of the
things people like about JSON).  I know you can do this with XML Schema
- but it melts your brain and potentially requires additional networking
round trips.  With oBIX we require that this level of reflection is
embedded in each and every document.

One cool thing we did with oBIX was implement "types" via prototype
inheritance.  In oBIX a type definition is called a "contract", which is
itself just a normal oBIX document.  Unlike schema based solutions, this
means you don't need one language to describe types and another language
to describe instances (once again we didn't want to require oBIX
consumers to understand something like XML Schema).  So in oBIX,
contracts are just normal instance documents.  Furthermore any instance
document with a URI can be a contract.  This design has the elegance
that types can be easily retrieved at runtime and consumed using the
same parsing libraries.  In fact, most of the oBIX specification is
written in oBIX itself to define the standardized contracts.

Between reflection of primitives and contracts we have a good start
toward building semantics into oBIX documents.  However we don't want to
bind ourselves up into a rigid, strongly typed straight jacket.  One of
our requirements was that understanding contracts should be optional.
You can use contracts in an ad-hoc fashion to "tag" documents with
semantics, but nothing in the specification requires consumers to know
about those contracts ahead of time.  Standards organizations can define
contract libraries for normalized semantics, but vendors can define
proprietary contracts to achieve high fidelity with their existing
systems.  Another way to think about oBIX contracts is as a cross
between formal ontologies and folksonomies. 

Last but not least, we stuck with REST as our underlying architectural
model.  Anything out-of-band in an oBIX document is identified using
URIs.  oBIX has its own version of the HTML anchor tag for
cross-referencing other oBIX documents with URIs.  Plus contracts
themselves are just oBIX documents identified with URIs.  Effectively
this lets us wire together oBIX data into a machine web across the
Internet.  And just like the HTML web, its "crawlable" using the same
principles of discovery.

If you're interested in reading the spec:
 
http://www.oasis-open.org/committees/download.php/21812/obix-1.0-cs-01.p
df
 
http://www.oasis-open.org/committees/download.php/21462/obix-1.0-cs-01.z
ip

Plus there is an open source implementation in Java:
  http://sourceforge.net/projects/obix 

I'd be very interested in hearing feedback from you XML gurus!

Brian


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS