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”/>
</real>
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: [mailto:]
On Behalf Of Bogen, Chris ERDC-RDE-ITL-MS
Sent: Thursday, August 07, 2014 10:58 AM
To: Toby Considine;
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.
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
