> On 12 Nov 2015, at 08:51, 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
OK, I agree to add up votes for c) and e). Lada > > /js > > -- > 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/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
