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