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: RE: [obix] Problems with WD29

I’m not sure we’re all on the same page here.


The ‘name’ attribute is not being used to hold anything other than the name of the object.  The metadata is being represented with obix objects themselves, so their ‘name’ attribute is just their name.  There is no ‘overloading’ of the ‘name’ attribute.  It’s just another object:


<real href="" name=”Room101” val=”70.0”>

  <obj name=”hvac:temperature”/>

  <obj name=”hvac:setpoint”/>

  <int name=”building:roomNumber” val=”101”/>

  <int name=”building:floor” val=”1”/>

  <str name=”building:buildingName” val=”MyOffice”/>

  <uri name=”hvac:vavReference” val=”/bldg/vavs/vav101”/>



In the example above, from the spec WD29, the obj with the name “hvac:temperature” is an object itself.  If you look at the system, it is just the same as any other object, we’re not stuffing anything extra into its name attribute.  It’s just another object.  That’s the beauty of the compositional model, you just use objects for what you need.


I guess I still don’t see Toby’s problems here.


From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Bogen, Chris ERDC-RDE-ITL-MS
Sent: Thursday, August 07, 2014 10:58 AM
To: Toby Considine; OBIX@lists.oasis-open.org
Subject: RE: [obix] Problems with WD29


I concur with your opinion Toby.  Name needs to be kept as simple as possible as it has such a strong relationship to the object’s identity, and it does seem like a hack.


Deciding on the name of the foo attribute should be relatively trivial though I have no idea what impact this has on work that is currently in the pipeline.






From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Toby Considine
Sent: Wednesday, July 30, 2014 9:26 PM
To: OBIX@lists.oasis-open.org
Subject: [obix] Problems with WD29


I think we have a problem with the proposed us of “name” to hold all metadata. My concerns are strong enough that I would not vote to release at this time.


Name already means something else. Packing metadata into the name variable disturbs me. A lot. I perhaps could be talked out of this, but the conversation is not happening. I know I am not the only TC member who feels this way about overloading Name in this way.


It reads like a hack, that makes sense of a given item *may  have one or two metadata items. I don’t believe that is true. Sticking solely with Haystack:


For a single air handler, we may have most of the tags below: (I know a few of them are exclusive.)



Air Handler Unit which heats and/or cools air.



Marker tag used with water for the chilled water system between chiller and ahu.



Marker for an ahu which delivers air to zones via chilled beam terminal units.



Chillers remove heat from a liquid via a vapor compression or an absorption refrigeration cycle.



Chiller plants model the entire system of equipment used to generate chilled water.



Associate a record such as an ahu with its chillerPlant.



Cooling coil as bool or numeric point used with ahu equip.



Associated with the cooling mode of an HVAC system



Marker for an ahu which delivers air directly to a zone.



Associated with the discharge air an ahu or vav.



Indicates an ahu which discharges into two ducts which are some combinatin of hotDeck, coldDeck, or neutralDeck.



A boolean point of an ahu indicating a freezing condition which might require a control sequence to protect the equipment.



Heating coil as bool or float point on an ahu or vav.



Bool point which models the on or off state of an ahu heat wheel.



Boolean or numeric point of an ahu used to indicate if if the humidifier is on or off.



Associated with the mixed air of an ahu.



Marker for an ahu which delivers air to its zones via a ductwork manifold which splits the air into a duct per zone.



Associated with outside air, often used to model ahu points.



Used with ahu to mark an AHU as a packaged rooftop unit (RTU).



Indicates an ahu which discharges into three ducts which are the hotDeck, coldDeck, and neutralDeck.



Marks an ahu as delivering a variable volume of air flow.



Marker for an ahu which delivers air to zones via vav terminal units.


The add a few BIM tags, and a few regulated environment tags…


I don’t think this belongs in the Name attribute.




If it belongs in the foo attribute, then we need


a)      To decide what to call the foo attribute

b)      Update the schemas (XSD) to include an optional [foo] attribute

c)       Update the list of attributes in the prose to include the foo attribute



We are also creating, nay, mandating a standard contract for namespaces in the lobby. We should add the Namespace contract as an explicit schema in the XSD.



"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

- Brian W. Kernighan

Toby Considine
TC9, Inc

OASIS TC Chair: oBIX & WS-Calendar

OASIS TC Editor: EMIX, Energy Interoperation

SGIP Smart Grid Architecture Committee


Email: Toby.Considine@gmail.com
Phone: (919)619-2104

blog: http://www.NewDaedalus.com


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