[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Interesting XML ideas in oBIX

• From: noah_mendelsohn@u...
• To: "Brian Frank" <bfrank@t...>
• Date: Tue, 16 Jan 2007 11:42:34 -0500

Brian Frank wrote:

> XML Schema gets grumpy when you try to have previously unknown 
> elements like <e> floating around in your documents.

The XML Schema workgroup is well aware of the need to make the language 
more usable for vocabularies that are either evolving, I.e. likely to be 
changed by the same parties that controlled the original versions, and/or 
extended, perhaps by 3rd parties as in your Spinal Tap example.  Indeed, 
supporting such "versioning" scenarios is a main goal of the upcoming 
Schema 1.1 revision.  Here are some resources that may be of interest:

* For a quick guide to some of the new features provided in support of 
versioning and open content, see the working draft "Guide to Versioning 
XML Languages using XML Schema 1.1" [1]

* For the latest published working draft of the Schema 1.1 specification 
see [2]. 

* If you're really interested in details some of the mechanisms and 
alternatives that were considered, the use cases that were evaluated, 
etc., see [3], which is a public Web page at which the Schema WG is 
collecting links to much of what the workgroup considered in this space.

I should also acknowledge that languages like Schematron have value when 
you prefer not to set out a grammar even for the parts of the language you 
are expecting.  You can either use Schematron by itself to check 
particular constraints (in the form of XPath expressions).  Note that with 
Schema 1.1, it will be easier if you wish to write a grammar that is 
relatively open, in the sense that you can require the constructs you that 
are essential, but make the content "open" to additional (Spinal Tap) 
content as well.  Then you can use either the new XPath-based 
co-constraint mechanism that's also in Schema 1.1 or Schematron to enforce 
additional checks if you wish to.

Noah

[1] http://www.w3.org/TR/xmlschema-guide2versioning/ 
[2] http://www.w3.org/TR/xmlschema11-1/
[3] http://www.w3.org/2005/05/xsd-versioning-resources.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Brian Frank" <bfrank@t...>
01/16/2007 11:03 AM
 
        To:     "XML Developers List" <xml-dev@l...>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE:  Interesting XML ideas in oBIX


> 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


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

• Follow-Ups:
  • RE: Interesting XML ideas in oBIX
    • From: "Brian Frank" <bfrank@t...>

• References:
  • RE: Interesting XML ideas in oBIX
    • From: "Brian Frank" <bfrank@t...>