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: 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 Echelon's
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 developers
down to specific definitions for even the common data types found in control
systems. This reminds some of us at Echelon of the time before LonMark
Standard Network Variable Types. When we formed the LonMark association with
our customers, the first thing we needed was a set of standard data types to
avoid gratuitous differences in otherwise equivalent definitions. That was
only the beginning, however, as then we found we needed to group these
standard types into collections (called functional profle templates) that
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 to
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. We
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 derived
contract cannot take things away from the parent contract. It is not clear
yet whether this also applies to the object - if it is a problem, then Obix
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
desirable.
 
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 children,
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 details
the implicit contract. This is not a failure of the current obix proposal,
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 describes
this relationship. Unless client software knows about, and honours, this
relationship, the channel still has a valid 2-200 range. For this particular
example, it would have been better to show that "channel" can be overridden
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, a
single obix subscription could request a field within a single object, or
the same field from three different instances of the same contract (i.e.
three network variables, one one each device, where all devices share the
same template). How is it going to do that?

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

Thanks, and since I'm so new to this, please excuse anything that seems too
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]