Talk:V4 Standard Properties and Events

1. I think that it is important from the start to clearly define the timestamp, alarmSeverity, alarmStatus, units etc to be subordinates of the value property. Therefore they would be one level further down in the hierarchy. Specifically, if value is 1.1 then timestamp should be 1.1.1 and alarmSeverity should be 1.1.2 etc. Same thing with bullet delineated lists - the value property might be further over to the left and things below it should be on tab stop to the right. This approach allows multiple values to be in the same record. For example, we might have an "xPosition" and a "yPosition". The paradigm where the limits and the value are at the same level in the hierarchy fits from a C programmers perspective because that is how one tends to make u p structures, but it tends to break down when designing external interfaces for the system. For example, one might have a single property named "xPosition" that is a double. Later, when adding limits for "xPosition", a backwards incompatible property hierarchy change has to occur when this double is changed to an "xPosition" container that has a double in it who's property name is "value".
2. Hopefully, we can avoid having to place "value", which does not convey any additional meaning, in any V4 channel name. For example we might have channel names like the following.

• single value channel names
  • analogDevice10
  • analogDevice10/timestamp
  • analogDevice10/diplayLimits/high
• dual value channel names
  • axisDevice10/xPosition
  • axisDevice10/yPosition
  • axisDevice10/xPosition/timestamp
  • axisDevice10/xPosition/diplayLimits/high
• Should a user supply any of the following channel names they would not find a matching service to connect to (hopefully there would be an error message identifying the available choices when they specify a leaf missing from the hierarchy).
  • axisDevice10
  • axisDevice10/timestamp

1. Perhaps we should use "." (a dot) only for backwards compatibility and use a "/" (slash) to denote 4.0 hierarchy? For example a CA channel name might look like "myChannel/timeStamp", "myChannel/xPosition/diplayLimits/high", or "myChannel.HOPR". Just thinking out loud here.
2. I'm not sure how hierarchies of properties interact with this concept of a view. I see that a view is intended to be a very general approach with the option for an application specific plug in interpreting the view parameters so I should probably wait to see what you will define in the doc later. Nevertheless, I am still wondering if you will allow hierarchy in the channel name prior to specifying the view for the end leaf?
3. The need for a list of fields appears to be driven by (A) backwards compatibility (see comment about "." above) and (B) the need to have an unambiguous list of all properties necessary to maintain a backup of the state of a record with the option of restoring it later. Related to (B) I certainly do understand the issue that portions of the records state could show up multiple times in the generalized property hierarchy. A negative related to placing the concept of fields in public interfaces is of course additional complexity and with complexity confusion, potential for code bloat, and training class bloat. Perhaps one solution would be to add a capability to make an "all properties read" request that is further constrained to send internal state only once, and thereby eliminate leaves in the property hierarchy that might be redundant when expressing the internal state. Just thinking out loud again here.
4. It might be best to avoid more than four properties at any given level in the hierarchy. There can be important performance advantages associated with that organization from a dataAccess interfacing perspective, and perhaps this will make the code, and documentation, more modular as well.