Open kwatsen opened 4 years ago
do not support removal. continue to recommend anydata instead of anyxml
IMO nobody actually implements these 2 statements differently. It is a non-problem
YANG 2.0 should recognize the difference between errors and warnings. Use of anyxml in a YANG 2.0 module should cause a warning message to use anydata instead
Do not support removal at all since this is an extreme NBC change. A "deprecation phase" MUST be done first. Maybe remove in YANG 3.0 if that ever happens.
Synopsis:
The "anyxml" statement made since in RFC 6020, before JSON support was added, but its value is questionable now...
Propose to remove (if YANG-next == YANG 2.0) or deprecate (if YANG-next == YANG 1.2).
More info:
RFC 7950, Section 1.1 (Summary of Changes from RFC 6020) says:
RFC 7951, Section 5.6 (5.6. The "anyxml" Data Node) provides very little guidance for how to encode an "anyxml" node in JSON, other than saying that it
the value MUST satisfy I-JSON constraints
.CBOR support follows the same example: draft-ietf-core-yang-cbor-12, Section-4.6 (The 'anyxml')