RE: [obix] Problems with WD29

From
Bogen, Chris ERDC-RDE-ITL-MS <>
Date
2014-08-07T14:58:09+00:00
ID
Thread
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.

 

Regards

 

Chris

 

From:  [mailto:]
On Behalf Of Toby Considine

Sent: Wednesday, July 30, 2014 9:26 PM

To: 

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.)

 

ahu 

Air Handler Unit which heats and/or cools air.

 

chilled 

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

 

chilledBeamZone 

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

 

chiller 

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

 

chillerPlant 

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

 

chillerPlantRef 

Associate a record such as an ahu with its chillerPlant.

 

cool 

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

 

cooling 

Associated with the cooling mode of an HVAC system

 

directZone 

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

 

discharge 

Associated with the discharge air an ahu or vav.

 

dualDuct 

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

 

eezeStat 

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

 

heat 

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

 

heatWheel 

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

 

humidifier 

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

 

mixed 

Associated with the mixed air of an ahu.

 

multiZone 

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

 

outside 

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

 

rooftop 

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

 

tripleDuct 

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

 

variableVolume 

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

 

vavZone 

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.

 

tc

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


Phone: (919)619-2104

http://www.tcnine.com

blog: http://www.NewDaedalus.com