RE: [xml-dev] Interesting XML ideas in oBIX

["Brian Frank" <bfrank@tridium.com>]

> If I understand your requirement correctly, it is already provided 
> for in the XML Schema Recommendation, at least insofar as what you 
> wish to type are elements, as opposed to attributes.  The xsi:type 
> attribute [1] is provided so that you can assert the type of an 
> element in the instance.  Consider the following two examples, 
> presuming the conventional namespace prefix bindings:
> 
>        <e xsi:type="xs:integer">123</e>
> 
> You have asserted that <e> is an integer.  In particular, you have 
> asserted that its type is specifically the integer type specified in 
> the XML Schema Recommendation [2].  The W3C controls that type
definition, 
> and it is unlikely to change.  I think you've achieved what you want.

I definitely agree that XML Schema primitive types are right way to go.
But the xsi:type attribute approach didn't fit well into our bigger
problem.  We desire to make oBIX work over SOAP, which in turn means
that we need the ability to describe the payload with XML Schema.  That
requires the whole oBIX document can be described with an XML Schema.
XML Schema gets grumpy when you try to have previously unknown elements
like <e> floating around in your documents.  Furthermore it is desirable
to embed XML Schema like facets into instance documents themselves.  For
example, given an int we might include a min, max, or units attribute.

We explored various approaches to this problem, best illustrated with an
example.  Consider an XML document used to describe the state of your
stereo.  Let's say in an unusual gesture of goodwill to simplify
consumers life, the audio-visual manufacturers got together to
standardize "volume" as an integer element from 1 to 10.  We might now
publish the state of our stereo as something like this:

  <s:stereo xmlns:s="http://standards/stereo/";>
     <s:volume min="1" max="10">3</s:volume>
  </s:stereo>

At long last, I can seamlessly control the volume on all my equipment
right out of the box!  But now Spinal Tap, Inc comes along and they have
this great idea for their value add - they are going to make their
stereo volumes go to 11!  They need to stick with the standard to make
their equipment interoperable, but they really want to publish their
proprietary "volume plus" feature in their XML too:

  <s:stereo xmlns:s="http://standards/stereo/";>
     <s:volume min="1" max="10">3</s:volume>
     <volumePlus min="1" max="11">3</volumePlus>
  </s:stereo>

In my experience this is perhaps one of the most fundamental challenges
of standards efforts - how to create normalized models to provide
interoperability, but embrace vendor specific extensions to promote
differentiation and innovation.  So the question is how do we define an
XML language to deal with this case?  We don't want to create "schema
explosion" and force XML consumers to understand a laundry list of XML
Schemas before they can get this document through their SOAP stack.

How we decided to solve it was fairly simple (and a bit of cheating) -
we broke the problem into two layers.  The first layer defines a fixed
XML grammar which is completely defined by a single XML Schema.  The
second layer defines how to tag elements with semantics using the
contracts concept I touched on before.  That approach led us down the
path of using the element name to indicate the type, and using a "name"
attribute to define the element's role.  So in oBIX the above example
would be:

  <obj is="http://standards/stereo/ http://spinaltap/stereo/";>
     <int name="volume" min="0" max="10" val="3"/>
     <int name="volumePlus" min="0" max="11" val="3"/>
  </obj>

The XML itself describes a simple tree of primitives.  The semantics are
pulled out of the schema and into a higher layer - in this case a list
of contract URIs identified by the "is" attribute.  So far it seems to
work really well.

But I'm curious other people solve this problem?

Brian