OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

obix-xml message

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

Subject: RE: [obix-xml] Telecon Wednesday 2/22

These are great comments Bob.  Hopefully we can go through these with
the group on a conference call which you can attend (if you don't make
this Wed).  In the meantime, I will provide my feedback regarding each

1. We believe that the basic primitive types and predefined point types
cover the majority of cases necessary for "point level" integration -
which I believe is largely the domain covered by SNVTs.  It's a bit
different because we don't distinguish based on bit-wise size -
everything is just 64 bits.  And we don't distinguish based on
measurement quantities, rather we just use int or real, and tag
measurement quantity with the unit facet.  I do hope that higher level
contracts for things like VAVs, access cards, etc will be defined as
oBIX contracts.  But I see that better tackled outside the core spec,
within more vertical domain organizations such as LonMark.  My personal
experience is that most enterprise integration takes place at the point
abstraction level, not at the higher device/profile abstraction levels.
Higher level abstractions are very useful for humans, but tend to be
hard to put to good use for automated integration (such as predefined
graphics/UIs or application bindings).

2. Object oriented languages don't tend to have unions, but rather
tackle that problem with inheritance.  For example if I have a field
that can be either A or B, then typically I have declare the field to be
a superclass (say it's called C) that both A and B implement.  Of course
sometimes (like most OO languages) this can be tricky if you don't have
access to A's and B's definition to ensure a common contract.  Although
this constraint exists in OO languages, it doesn't seem to be a
practical problem since you can also just say something is an obj (plus
oBIX has more flexible duck typing).

3.  I think this is has always been one of the shortcomings with all
object oriented models.  In some respects, oBIX makes this much easier
to solve using finer grained contracts that can be mixed in - a great
example is that we didn't make acks an optional part of Alarms, but
rather a different mixin contract.  There are other techniques available
such as the ability for oBIX to add new objects to any instance, which
makes it more flexible than statically typed models (in Niagara we use
this approach extensively to do dynamic/optional modeling).  Another
technique is just to declare a child, but null it out in an
implementation if it isn't applicable.  I'm not intimately familiar with
functional profiles, but my understanding is that they are typically
used to advertise standard functionality, in which case probably using
mixin contracts would be the preferred approach.

4.  I don't quite understand this comment, so you'll have to explain
"applies-to" for me.

5.  General comments:
i.  Good catch, I changed the verbiage to be more explicit for 0.9.1
ii. We talked about this a long time ago, and would probably be a good
thing to discuss as potentially another attribute or standard contact
iii. Yes, I can see where the example would lead to confusion - I
reworked the example to use volume since lastChannel was a poor choice
for a new object definition
iv.  I'm not completely sure I understand the issue, but I think hrefs
take care of this for you.  If an object has an href you read/watch it's
extent.  If you have three different devices being modeled, the would
each have their own href - I am on the same page?

I don't think there is anything really preventing oBIX from being used
for user interfaces.  As a matter of fact, the open source project does
provide a default UI to view/edit oBIX objects.  Of course UIs cover a
broad spectrum - what we have now does a good job with simple
auto-generated property sheet style UIs, but it's a long way from being
to a full UI language such as SVG or XAML (although you could
conceivably see integration with such technologies).  So my suggestion
would be that if you have comments, let's discuss them.

Thanks for the thorough read!


-----Original Message-----
From: ahansen@tridium.com [mailto:ahansen@tridium.com] 
Sent: Monday, February 20, 2006 11:56 AM
To: obix-xml@lists.oasis-open.org
Subject: [obix-xml] Telecon Wednesday 2/22

The following is from Bob Dolin of Echelon.


From: Bob Dolin
Sent: Mon 2/20/2006 8:33 AM
To: obix-xml@lists.oasis-open.org
Subject: Telecon Wednesday 2/22

I am on vacation this week so I probably will not be able to join the
telecon. However, so as to not hold things up, I'd like to forward
comments on the 0.9 oBix draft for your consideration.
1. There is a general concern within Echelon that oBix data is
underspecified. The contract mechanism while general does not tie
down to specific definitions for even the common data types found in
systems. This reminds some of us at Echelon of the time before LonMark
Standard Network Variable Types. When we formed the LonMark association
our customers, the first thing we needed was a set of standard data
types to
avoid gratuitous differences in otherwise equivalent definitions. That
only the beginning, however, as then we found we needed to group these
standard types into collections (called functional profle templates)
provided a standard interface to a set of common devices -- VAVs, access
card readers, etc. We wonder if a single data center could easily talk
multiple oBix access points created by multiple suppliers given the very
open and flexible nature of contracts. We would recommend making some
standard contracts for data types that are currently in use. The LonMark
standard network variable definitions come to mind, I'm sure there are
others for other control communications systems.
2. LonMark has some data types that are structures that contain unions.
don't understand how to model a union in Obix.
3. If one wanted to model a LonMark Functional Profile Template in obix,
this model would include optional members (sub-objects) which may not be
implemented on a particular device instance. We are not sure if obix
supports this. We think that obix requires an exact match between the
template and the implementation. Since object inheritance cannot remove
stuff from the derived point, how would one deal with optional, not
implemented, FPT members? 
(Lines 690-694) confirms this - contract compatibility means that a
contract cannot take things away from the parent contract. It is not
yet whether this also applies to the object - if it is a problem, then
cannot model the LonMark funcitonal profile template concept, I think.
4.  Connected with the previous point, Obix has only one way to describe
relationship between items: inheritance. An "applies-to" relationship,
as we
use in LonMakr Device Resource Files, is not present and would be highly
5. Some general observations:
i.  (Line 412) "Within a given object, all of its sub-objects must have
unique names" - presumably this only applies to the given object's
not to its grandchildren? The scope of a name needs clarifying.

ii.    (557-560) There seems to be no standard syntax for associating an
implict contract with the explicit one. The implicit contract could, for
example, be required to provide a http URL to a public document that
the implicit contract. This is not a failure of the current obix
but the addition seems desirable.

iii.  (568-576) The example seems unfortunate, as the derived object
adds a
new element ("lastChannel") which does nothing but limit the channel
elements value range. This is unfortunate because nothing in obix
this relationship. Unless client software knows about, and honours, this
relationship, the channel still has a valid 2-200 range. For this
example, it would have been better to show that "channel" can be
to limit the parent channel's properties like so: <int name="channel"
max="13"/>. For a demonstration of a newly added element, some unrelated
aspect like "brightness" might have been a better choice.

iv.   It is not clear to us how nested names are encoded. For instance,
single obix subscription could request a field within a single object,
the same field from three different instances of the same contract (i.e.
three network variables, one one each device, where all devices share
same template). How is it going to do that?

We would have more comments if the scope of Obix was to create the
for the clients to be user interfaces, but we believe this is outside
scope of the current release. Is our belief correct?

Thanks, and since I'm so new to this, please excuse anything that seems
ignorant. I'm learning by just reading and commenting -- and shortly, by
listening to the group's responses.

Bob Dolin

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