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


Below is an email Bob tried unsuccessfully to post along with my
comments...

Regarding 1, 3: I believe oBIX supports your requirements - however our
only intention is to provide the flexible foundation to enable features
such as function profiles.  I believe higher level abstractions such as
functional profiles are easily specified as oBIX contracts and provide
the rigidity you are looking for, but they should be done via standards
work outside of the core spec.  Think this oBIX spec as the kernel in a
stack of specifications.

Regarding other facets or meta-data items:  the foundation we have could
likely model just about anything.  I would base that statement on the
fact that oBIX is a richer modeling language than Java, and we've been
able to use Java to model lonworks, BACnet, a lot of other things.  The
question really boils down to what's baked into the core spec with first
class support versus what is achieved through aggregation features like
object and contract composition.  I obviously want to keep the core spec
as lean as possible, but if we come up with good use cases that apply to
a broad range of problems, then we should discuss what it would mean to
roll them into the kernel spec at a low level.  As a general rule I
believe it's always better to start off leaving things out, and adding
them later as we fully understand them (or better yet addressing them in
at a higher level in the stack).

Regarding unions: Jeremy sent an example, which I will reply to
separately.  You raise a couple of the points regarding discoverability
which I will try to address too.

Regarding applies-to: we discussed this, and basically that is that the
'ref' object is for - to create a "property" or "field" that references
another object via it's URI.  In your specific Lonworks case I might
model that as:

  <!-- contract definition -->
  <obj href="lon:Applicable">
    <list name="appliesTo" of="obix:ref"/>
  </obj>

  <!-- example -->
  <reltime name="heartbeat" is="lon:Applicable">
    <list name="appliesTo">
      <ref val="prop1"/>
      <ref val="prop2"/>
    </list>
  <reltime>

I think there a couple points we talked about discussing on the mailing
list, plus a couple action items for me to enhance the spec - hopefully
we will be having another voice call shortly where we discuss some of
these things easier than email.

Brian


-----Original Message-----
From: Bob Dolin [mailto:bobd@echelon.com] 
Sent: Wednesday, March 01, 2006 1:23 PM
Subject: RE: [obix-xml] Telecon Wednesday 2/22

I tried a reply all at first and the address
obix-xml@lists.oasis-open.org
would not accept this email. So, I'm sending it explicitly to the four
of
you. Feel free to send it to whoever else would be interested.
Thanks,
-bob

________________________________________________________________________
__


Hi Brian, 
I had a conflict this morning that couldn't be moved so I missed the
telecon. Sorry! I do plan to be on Toby's this afternoon, however.
Anyway,
here are some comments on your comments:

Regarding items 1 and 3: We think the conflict comes from different
intentions or requirements. Brian designs a loosely tied system for
"point
level" integration, while we would probably want a flexible yet firmly
tied
contract system: we'd want to be sure SFPTxyz (standard functional
profile
template xyz) is in the box if the label says so. FPTs present the
particular problem of optional members as part of the standard contract;
We
need to understand how obix supports this. 

Maybe the solution to this would be to add an implementation="optional"
or
implementation="required" facet to all points that can be described
within a
contract? 

LonMark device resource files (DRF) also supports other facets that will
probably make things difficult for a strictly object oriented approach.
For
example, member configuration properties (CP)  carry a "must be
implemented
as an array with N..M elements" / "may not be implemented as an array"
aspect, members and types carry min/max/default/invalid value data, etc.



Regarding item #2, unions: We can see inheritance as a way to READ union
data. When writing union data such that the union key changes, we need
to
understand how that would work, or if not, that the intention of obix is
just to upload information. We don't see that the obix server has a
method
of publishing a dictionary of contracts to start with, so we don't know
how
will the client know which contract to choose for writing. 

For example: implement a superclass S, and derive 3 different "union
variations" A, B, and C from it. A, B, and C would all derive from S.
The
client can chose one (for writing), provided it has knowledge of that
list. 
Further, we cannot recall an "abstract" attribute in obix. This would be
desirable to prevent implementation of S.

Since I'm pretty new to obix, this might just be a display of my
ignorance,
so please feel free to point me to things that get me up to speed.

Regarding #4: Applies-to: In LonMark, there are single items that apply
to
more than one object without any inheritance relationship. For example,
one
can have a SINGLE heartbeat timer that applies to certain (but not all)
elements in several control objects.  We call this capability fan-out
applies-to relationships: a single CP can apply to more than one item. A
good reference for the "applies to" constructs in LonMark is in the
LonMark
resource editor documentation available on the LonMark website:
http://www.lonmark.org/products/snvtfile.htm

Regarding item 5.ii: href: We do agree href could couple implicit and
explicit contracts, but this we think it would be better if this was a
part
of the language, not some possible implementation-specific addition.
For describing relationship between two points, such as "lastChannel"
and
"Channel", We're not sure that href is sufficient. This particular
example
was poorly chosen, granted. Similar syntax is needed to describe
"applies-to" lists, though.

Anyway, I plan to dramatically improve my attendance on the conference
calls, again, sorry for this morning's absence.

-bob

-----Original Message-----
From: Brian Frank [mailto:bfrank@tridium.com]
Sent: Monday, February 20, 2006 1:57 PM
To: obix-xml@lists.oasis-open.org
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
issue.

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!

Brian

-----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
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]