On Sat, Nov 14, 2015 at 1:27 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> > > 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. > This is really vague. The rules should not change for anyxml, so (c) is the best choice. If somebody actually reported 2 real-world tools that are currently broken because of anyxml misinterpretation, then this issue would be relevant. Got any examples to share? If not, then let's pick (c) and move on. 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?" > Lada > Andy > > > > > /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
