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". Interoperability expectations should be very low for anyxml. We already established that over 1000 emails ago. /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
