SSD variants #20
SSD variants #20
Conversation
|
Documentation is currently missing |
|
Similar to the other PR, this needs to be redone so the actual changes are visible. However I do not think this is a good idea in general, because it allows contradictory information that implementations then need to handle: I can state that an SSD is an e.g. parameter variant of another SSD; however nothing ensures that this is true, so an implementation more or less has to check and handle inconsistencies anyway. In that case I can already deduce it is a parameter variant algorithmically, and the new information does not add anything to the picture, except maybe intent (the name of the variant for user-selection is already given by the SSD meta-data attributes according to our current spec). It does not even provide any indication which parameters or component has changed, so again I need to do a full differential analysis of the SSD contents, which would then already give me all the information in the new element, except a directionality (which to consider the base and the derivative), however there often is no such thing anyway, as e.g. 3 parameter variants will very often not usefully be described by base + 2 derivatives, but rather just 3 parameter variants on equal footing. If we want to support parameter variants and/or component variants in a better way than we currently can, I think more structural changes are needed. Just my two cents as of now. |
|
Yes this is a "lightweight implementation" that aims to add variant semantics that are currently missing. |
Proposal for SSD variants with clearer semantics, specifying the base SSD of a variant and the kind of a variant (parameterization and/or component implementation variant).