RE: Despite loss of Power, OBIX meeting

Adding to my late start (snow, loss of power, loss of water, loss of network), GoToMeeting “decided to chage the meeting number

 

 

https://global.gotomeeting.com/join/973719869

 

Full information in SoapHub, as always.

 

tc

 

“It is the theory that decides what can be observed."

—Albert Einstein

Toby Considine

Phone: (919)962-9073

Information Technology Services

University of North Carolina

Chapel Hill, NC 

Email:


Chair, OASIS OBIX Technical Committee

Chair, OASIS WS-Calendar Technical Committee

Editor, OASIS EMIX, Energy Interoperation TC

 

From:  [mailto:]
On Behalf Of Considine, Toby

Sent: Thursday, February 26, 2015 10:46 AM

To: 

Subject: [obix] Despite loss of Power, OBIX meeting

 

Craig would more or less like to accept the comment on tags

https://lists.oasis-open.org/archives/obix-comment/201412/msg00001.html

 

Wishes discussion before he re-writes.

 

 

5.5.3 Encodings

Typo in para 1, should "This is a list of  strs. The val of each str"

 

9.4 Metadata

This is a better design than the last version.  But it still seems unsatisfactory when it comes to how it will be applied to Haystack tags.  In Haystack the vast majority
 of tags are marker tags which the proposed oBIX spec requires those tags to be sub-objects.  But in reality marker tags are much closer to oBIX contracts.  I think it would be cleaner to define marker tags in the "is" attribute using their tagspace as their
 prefix.  Consider:

 

  // proposed version

  <obj displayName="Discharge Temp Sensor">

     <obj ts="h" name="discharge"/>

     <obj ts="h" name="temp"/>

     <obj ts="h" name="air"/>

     <obj ts="h" name="sensor"/>

     <obj ts="h" name="point"/>

  </obj>

 

  // versus simpler design

  <obj displayName="Discharge Temp Sensor"

   is="h:discharge h:temp h:air h:sensor h:point">   

  </obj>

 

14.1 History Object - HistoryCollection

The terms "collection" and "HistoryCollection" seem sort of generic and confusing.  How about "collectMode" and "HistoryCollectMode" 

 

14.1 History Object - prototype

Glad to finally see something like this.  However I am not quite sure how it works.  I think we need an example.

 

14.2.4.2 History Query as Preformatted List

This design requires two separate round trip requests which is pretty terrible for performance.  I think a requirement of this design is that once the history point is
 learned by the client system, that it can request history data with a single HTTP request.  I don't see that having an oBIX XML response before getting the data provides much value.  I would suggest this: just add a "format" field to the HistoryFilter object
 and when specified the result is returned in the requested MIME type.

 

 

"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:


Chair, OASIS OBIX Technical Committee

Chair, OASIS WS-Calendar Technical Committee

Editor, OASIS EMIX, Energy Interoperation TC