You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose that these tests are removed from
"negative-tests.json":
[ "{keys:1}", false ],
[ "{+keys:1}", false ],
I guess that the author of these tests thought of this
extract from the RFC:
Prefix modifiers are not applicable to variables that
have composite values.
The normative part of the RCF does not seem to explicitly
say what "not applicable" means. The algorithm in
"Appendix A" of the RFC
(https://www.rfc-editor.org/rfc/rfc6570#appendix-A) seems
to ignore the prefix modifier for complex values (and would
therefore not pass the above tests).
Also the algorithm in "Appendix A" explicitly ignores
variables with an absent or undefined value. Keeping the
above tests would mean that evaluating a
"prefix-modifier-varspec" with absent/undefined value
should be tolerated while the evaluation must fail for
complex values. This is not the behavior I would have
expected after reading the specification.
The text was updated successfully, but these errors were encountered:
Appendix A is non-normative, and not meant to be considered a full implementation. Using a prefix modifier on a compositve value is at the very best not interoperable, because it is not specified; the specification's characterisation of it being 'not applicable' only reinforces that. So it's reasonable to expect failure in this case.
I propose that these tests are removed from
"negative-tests.json":
I guess that the author of these tests thought of this
extract from the RFC:
The normative part of the RCF does not seem to explicitly
say what "not applicable" means. The algorithm in
"Appendix A" of the RFC
(https://www.rfc-editor.org/rfc/rfc6570#appendix-A) seems
to ignore the prefix modifier for complex values (and would
therefore not pass the above tests).
Also the algorithm in "Appendix A" explicitly ignores
variables with an absent or undefined value. Keeping the
above tests would mean that evaluating a
"prefix-modifier-varspec" with absent/undefined value
should be tolerated while the evaluation must fail for
complex values. This is not the behavior I would have
expected after reading the specification.
The text was updated successfully, but these errors were encountered: