> On 13 Nov 2015, at 19:19, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Wed, Nov 11, 2015 at 11:51 PM, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> wrote: > On Thu, Nov 12, 2015 at 08:10:51AM +0100, Ladislav Lhotka wrote: > > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > > > > > On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote: > > >> > > >> > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder > > >> > <j.schoenwael...@jacobs-university.de> wrote: > > >> > > > >> > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote: > > >> >> > > >> >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder > > >> >>> <j.schoenwael...@jacobs-university.de> wrote: > > >> >>> > > >> >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote: > > >> >>>> > > >> >>>>> > > >> >>>>> I wrote 'effectively deprecated' and here is the text in 6020bis. > > >> >>>>> > > >> >>>>> Since the use of anyxml limits the manipulation of the content, it > > >> >>>>> is > > >> >>>>> RECOMMENDED that the "anyxml" statement not be used to define > > >> >>>>> configuration data. > > >> >>>>> > > >> >>>>> It should be noted that in YANG version 1, anyxml was the only > > >> >>>>> statement that could model an unknown hierarchy of data. In many > > >> >>>>> cases this unknown hierarchy of data is actually modelled in YANG, > > >> >>>>> but the exact YANG model is not known at design time. In these > > >> >>>>> situations, it is RECOMMENDED to use anydata (Section 7.10) instead > > >> >>>>> of anyxml. > > >> >>>> > > >> >>>> The first paragraph is for config data and the second for data that > > >> >>>> can modelled with YANG. If we want to deprecate "anyxml" for use > > >> >>>> with data that are neither of these, 6020bis should say so. I'd be > > >> >>>> fine with that. > > >> >>>> > > >> >>> > > >> >>> The guidelines will say that any usage of anyxml in the IETF will be > > >> >>> carefully checked by YANG doctors. See Y34 for all details. > > >> >>> > > >> >>>>> There is more text in Y34-05 that will go into the guidelines. I > > >> >>>>> call > > >> >>>>> this "effectively deprecated", you can call it differently if you > > >> >>>>> want. Frankly, this thread is about how to encode anyxml in JSON > > >> >>>>> not > > >> >>>>> about the YANG 1.1 issue Y34. You may not like Y34-05 but this is > > >> >>>>> what > > >> >>>>> we ended up with. > > >> >>>> > > >> >>>> I am strongly against encoding serialized XML as JSON strings. It > > >> >>>> is IMO totally useless and the spec would have to deal with awkward > > >> >>>> complications because it is not true that arbitrary XML-encoded > > >> >>>> anyxml content can be used without changes in JSON encoding. > > >> >>>> > > >> >>>> Perhaps the best solution would be to state that JSON encoding is > > >> >>>> incompatible with data models that use "anyxml". > > >> >>>> > > >> >>> > > >> >>> Perhaps we can only settle this by doing an opinion poll since > > >> >>> debating this forever is not useful. So what are the options? > > >> >>> > > >> >>> a) The JSON encoding does not define anyxml is not encoded at all. If > > >> >>> you use anyxml in a data model, the content will not appear in JSON > > >> >>> encodings. > > >> >>> > > >> >>> b) The JSON encoding defines that anyxml data is encoded as a string > > >> >>> containing XML. > > >> >>> > > >> >>> c) The JSON encoding defines that anyxml is encoded in whatever way > > >> >>> the implementor finds useful. > > >> >>> > > >> >>> d) If the anyxml content is actually valid anydata content, encode it > > >> >>> using anydata rules. Content that is not valid anydata content is > > >> >>> not encoded at all. > > >> >>> > > >> >>> Any options missing? > > >> >> > > >> >> Yes, the one that's in yang-json-06: > > >> >> > > >> >> e) An anyxml instance is encoded as a JSON name/value pair which MUST > > >> >> satisfy I-JSON constraints. Otherwise it is unrestricted, i.e., the > > >> >> value can be an object, array, number, string or one of the literals > > >> >> "true", "false" and "null". > > >> >> > > >> >> My preference is e), and then a). > > >> >> > > >> > > > >> > Is e) not the same as c)? I assume that the JSON encoding will always > > >> > be valid JSON (or I-JSON to be precise). So it seems the only > > >> > refinement > > >> > of e) is the toplevel. > > >> > > >> c) sounds like the same data can be encoded in different ways depending > > >> on what the implementor finds useful, e.g. encode all numbers as strings. > > >> > > > > > > But e) says the same, I fail to see the difference here. > > > > The way how c) is formulated is rather suggestive: beware, this is > > non-interoperable by its very nature. I think it is as interoperable as > > anyxml in XML encoding. Without knowing the context, translating anyxml > > chunks from XML to JSON, and vice versa, is quite problematic even for > > b). > > e) is no better than c) in terms of interoperability > > > > (e) does not even make sense. "Otherwise" is never paired with "MUST".
That "otherwise it is unrestricted" was intended to mean "there are no restrictions other than this", so it looks like a gap in my understanding of English semantics. > > Interoperability expectations should be very low for anyxml. > We already established that over 1000 emails ago. > I agree, but on the other hand I think it can be useful in specific situations where both the client and server are prepared to understand and handle it properly. We cannot expect generic tools to do anything reasonable with it - it is only good to make sure they won't break. Lada > > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
