As a possible compromise, what about something like:
The JSON encoding defines that anyxml may be encoded in whatever way the
implementor finds useful, or even not at all. If a preferred custom
encoding is not being used, then it is suggested that anyxml data be
encoded as a string containing XML to maximize legacy interoperability.
Rob
On 16/11/2015 16:50, Andy Bierman wrote:
On Mon, Nov 16, 2015 at 3:55 AM, Juergen Schoenwaelder
<j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> wrote:
On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote:
>
> YANG 1.1 is going to take 2 more years if we slowly revisit
every issue.
> I thought the whole point of the issue tracker was to prevent
this sort
> of thing. The rule should be "what new details have emerged that
> should cause us to change the previous decision?"
>
Andy, please note that this is a discussion primarily around the JSON
document and not around the YANG 1.1 document.
That doesn't mean we haven't discussed this issue for a long time already.
I thought we decided anyxml is not that interoperable and so we have
anydata that is supposedly interoperable.
So why try to constrain the JSON encoding?
For anyone sending mixed mode XML encoded as JSON,
they can get creative and do whatever they want.
For everybody else, anydata is simple enough to encode and decode.
/js
Andy
--
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
