[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix] Problems with WD29
|
Okay, I misunderstood initially and now I’m a bit more confused. This should be on the agenda next week for sure though it’s going to be very difficult for me to make next week’s meeting. Though I think I can understand his point. Toby, are you objecting because there is no explicit distinction between the things that are metadata items and the things that are “living” objects? If so then the
issue seems to be more about overloading decomposition and less about overloading name.
Or if the issue IS about overloading name, then are you taking exception to the namespace prefixes as exclusive metadata tags? Whatever the case, let’s have a spirited discussion about it! -chris From: Gemmill, Craig [mailto:craig.gemmill@tridium.com]
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:
obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org]
On Behalf Of Bogen, Chris ERDC-RDE-ITL-MS 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:
obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org]
On Behalf Of Toby Considine 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]