Closed dlemire60 closed 1 year ago
Features is an enumerated list of the four items in 3.4.2.4: (versions, pairs, profiles, rate_limit), to which schema will be added. That is the single command that is mandatory for all consumers to support.
Properties is a black hole into which actuator profile editors can dump stuff that they want but don't want to document. (It was created when Efrain was writing a Tesla Powerwall profile, but didn't document what data he could get from the Powerwall.)
My preference is for Properties to disappear, to be replaced by a requirement for profile editors to create property tables for all Results to be supported by the Consumer.
Discussed at 8/10 working meeting, and consensus reached on removing properties. @dlemire60 will be preparing a corresponding PR. The PR will address both this issue and #389
Agree with your suggestion to remove the properties target.
LS v1.0 has the targets
ID | Name | Type | # | Description -- | -- | -- | -- | -- 9 | features | Features | 1 | A set of items used with the query Action to determine an Actuator's capabilities. 25 | properties | Properties | 1 | Data attribute associated with an Actuator.features
andproperties
, with descriptions in the target list (Section 3.3.1.2) that are insufficient to clearly distinguish the intent of each:The examples in Section 4.2 helps somewhat to clarify
features
; the example in A.3 illustrates a use ofproperties
but provide no additional explanation (e.g., where did the"battery"
property in the example originate?). The LS should provide more informative language that enables the reader to clearly understand how these targets differ and when / how each is appropriate.EDIT: related issue is #389