[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
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