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