Comments on Motion 42 (not 41): Decoration system, revised text
First on 20121221DecoSystemCirculatedA.pdf:
5.1, end of 2nd paragraph: "The permitted flavors..."
This suggests that only flavors explicitly described in the standard
are permitted. It seems to me that providing a non-standard flavor
(in addition to at least one standard flavor, of course) should not
cause non-compliance, though we may place requirements on the need
for proper documentation.
There is a risk of course that multiple different interpretations
of a flavor not initially included in the standard would make it
difficult to standardize such a flavor in a subsequent revision.
Is that sufficient to prohibit non-standard flavors?
5.2, last sentence. The concept of "loose common evaluation" is nice,
but I think we need to distinguish three levels of tightness:
Level 1 tight (described here), Level 2 tightest, and loose (could
be due to Level 2 difficulty constraints, or conceivably Level 1
computability constraints).
5.3, last sentence: I like the introduction of the "com" decoration.
6.1, top of page 14: I like the way expressions are introduced.
6.3, on optionality of "com" in single-flavor implementations.
For functions with decoration inputs, such as setDec() or isDec(),
the name (or enum value) of "com" should be available universally for
code portability reasons. If "com" is not supported, setDec(com,xx)
should set dac, and isDec(com,xx) should return FALSE.
6.3, 2nd paragraph at the top of page 15: "Flavors should define other..."
I think it should say "Flavors should define THE other decoration
values..." (without my emphasis). As written it appears to suggest
that flavors should define ADDITIONAL decorations!
Michel.
---Sent: 2012-12-21 16:36:01 UTC