This was discussed in the Core WG meeting today. The answers are as follows (copied from Marcello's slide edited in real-time during the meeting):
* About data could include vendor extensions o Josh pointed out that there was a discussion in the context of the IRB mail list ? Consensus was that was the intent * Config map contains at least one field that is also in About info o If something is in the config map does it need to be in the About data also? ? Given it may be a vendor extension, it should really be up to vendor what they do * Names of Vendor extensible fields: is there a naming convention? o Consensus is that the naming convention for extensions (vendor in particular) should use the reverse DNS convention like interface names From: Dave Thaler Sent: Tuesday, October 11, 2016 12:55 PM To: 'allseen-core@lists.allseenalliance.org' <allseen-core@lists.allseenalliance.org>; 'allseen-baseservi...@lists.allseenalliance.org' <allseen-baseservi...@lists.allseenalliance.org> Subject: Additional fields in About/Configuration data Use case: a vendor or a spec for a gateway to another protocol that provides more info wants to provide additional metadata fields that are standard in About & Configuration. The 14.12 About interface spec (https://allseenalliance.org/framework/documentation/learn/core/about-announcement/interface) does not say whether the metadata fields in About can be extended or must be only the set in the spec. The 14.12 Configuration interface spec (https://allseenalliance.org/framework/documentation/learn/core/about-announcement/interface) on the other hand explicitly states "The OEM or application developer can add additional fields." Questions: * Does this mean that it is NOT legal for OEM or app developer to add additional fields to the About data? * If an additional field is read-only, should it be added to aboutData, or configMap, or both? * If an additional field is read-write, should it be added to aboutData, or configMap, or both? * Is there any expected naming convention for the names of the additional fields? (e.g., to avoid future conflicts with anything that might be a standard) * Is it possible for a client app to reliably know the semantics of an additional field? (e.g., if the field name is unique enough? Or some other rule?) Dave
_______________________________________________ Allseen-core mailing list Allseen-core@lists.allseenalliance.org https://lists.allseenalliance.org/mailman/listinfo/allseen-core
