Lada,
this seems to be related to YANG 1.1 issue Y34 which we concluded with
consensus on Y34-05, which extends Y34-02. And Y34-02 says:
'anyxml' would still be used to represent unrestricted XML, as is
done in NETCONF.
Your repeated attempts to generalize anyxml does not give us
interoperability. In fact, Y34-05 says:
- Document that implementations MAY have restrictions for anyxml and
that anyxml is not necessarily interoperable; data model writers
should use anydata whenever possible.
- The guidelines document should say that YANG Doctors will review
each use of anyxml in IETF modules when YANG 1.1 is adopted to
avoid its use whenever possible.
Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
anyxml as a string that has XML inside makes sense.
/js
On Thu, Nov 05, 2015 at 02:54:56PM +0900, Ladislav Lhotka wrote:
> Hi,
>
> at the NETMOD session Martin proposed that JSON encoding of anyxml instances
> be changed so that it is required to contain a JSON string with well-formed
> XML serialization inside. His argument was that "xml" is part on the data
> node name and also that RFC 6020 says it is "an unknown chunk of XML". I
> think, however, that the name and definition were influenced by the fact that
> XML was the only encoding under consideration when 6020 was being written.
> IMO, the definition could thus be interpreted as "an unknown chunk of data
> that follows the syntax of the current encoding".
>
> Note that similar ambiguity of interpretations applies to 6020 statements
> about NETCONF, edit-config etc. - we saw it in the discussion about
> auto-delete behaviour.
>
> A practical problem of Martin's proposal is that it doesn't provide a
> symmetric option to send arbitrary JSON chunks in JSON encoding (that may or
> may not be modelled with YANG). An option would be to introduce a new data
> node "anyjson" but I think this is really a bad approach - shall we then also
> add "anycbor" etc.? IMO YANG statements and rules should be
> encoding-independent.
>
> I still think the best option would be to introduce "anydata" with my
> definition above so that in XML encoding it would be equivalent to "anyxml",
> and deprecate "anyxml". We can also introduce a substatement that could state
> that the instances of a particular anydata node are required to be modellable
> in YANG.
>
> BTW, it seems that yang-patch needs to be able to transfer anyxml instances,
> so is it really possible to exclude anyxml from anydata content?
>
> Lada
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
