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

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

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


Subject: Meta-notes on 20150226 meeting (attn Mattias!)


So, informal meeting today, we were sub-quorate, but some interesting stuff. We explored Brian Franks’ comments today, and came up with two overarching notions—one simple, but needing to be said aloud, and one which, for me, was a BFO (Blinding Flash of the Obvious).

One notion that we explored was that the ts (tag space) attribute can be on any OBIX object. Craig shared some examples of using them with a URI. These came from exploring some of the “tags with values” issues, using Haystack as an example. A sensor in the grill at the end of a duct attached to an AHU is not just a sensor, but it has a tag value for that kind of sensor, and a relationship to the obix object for that AHU, and that obix object of course has a URI. This becomes away to state unambiguously what this point “does” (measures outlet air temperature) in relation to a particular air handler.

The other implication of Brian’s proposal is that while OBIX may be the default space, and the source of default contract definitions, the OBIX name space is nothing special. This is good.

Under this thinking, an OBIX point, an OBIX Setpoint are in essence merely standard contracts named from the defined OBIX tagspace. obix:point merely names the tagspace for this contract. A Haystack or an OMNICLASS point is merely a standard contract type from another, non-OBIX tagspace. A medical equipment tag referencing a HL7 tagspace is just another non-OBIX tagspace. This feels correct.

This implies that references to o:pointer obix:point, a matter on which we have spent some time, fall into the normal XML behavior. An entity that uses o: is merely oversiding the default referencing prefix, which they can do by adding the OBIX namespace itself to the tagspace references in the Lobby. A Consumer Electronics Association tagspace  would be just as natural as Haystack one.

This feels clearer, and does not change the specification, although it does change some of the explication and conformance statements.

Big Issue, especially for Mattias:

Does the slight variant in the use of TAG break any thing, particularly anything the Alliance is doing? Once Craig publishes his new examples, I need your eye on this.

 

Issue punted for 2.0

Since the earliest days of OBIX, one could specify that a point participated in multiple contracts by saying

<obj displayName="Discharge Temp Sensor" is="h:discharge h:temp h:air h:sensor h:point"></obj>

 

In this case we express a collection as a single string separated by spaces. An alternate encoding used in one location of a spec is bad, but we certainly can’t touch that without breaking backward compatibility.

 

 


"Computers are useless. They can only give you answers."

—Pablo Picasso


Toby Considine
Phone: (919)962-9073
Information Technology Services
University of North Carolina
Chapel Hill, NC

Email: Toby.Considine@unc.edu
Chair, OASIS OBIX Technical Committee
Chair, OASIS WS-Calendar Technical Committee
Editor, OASIS EMIX, Energy Interoperation TC

 



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