Subject: [netmod] [Ladislav Lhotka] Re: yang-json document

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 08 Feb 2015 11:18:34 +0100

Juergen Schoenwaelder <[email-masked]> writes:

> On Fri, Feb 06, 2015 at 04:32:13PM +0100, Ladislav Lhotka wrote:
>> 
>> > On 06 Feb 2015, at 15:36, Juergen Schoenwaelder <[email-masked]> wrote:
>> > 
>> > On Fri, Feb 06, 2015 at 02:54:54PM +0100, Ladislav Lhotka wrote:
>> >> 
>> >>> On 06 Feb 2015, at 14:38, Juergen Schoenwaelder <[email-masked]> wrote:
>> >>> 
>> >>> On Fri, Feb 06, 2015 at 01:49:02PM +0100, Ladislav Lhotka wrote:
>> >>>> Phil Shafer <[email-masked]> writes:
>> >>>> 
>> >>>>> 
>> >>>>> What does the JSON for this look like?  I think the only viable
>> >>>>> answer is:
>> >>>>> 
>> >>>>>   "web-banner": "<p>This is <em>very</em> sensitive data </p>\n<img
>> >>>>>   src="mister-yuk.png"/>\n<p>I'm serious, dude</p>\n"
>> >>>> 
>> >>>> I don't think so, the following is IMO a much better option:
>> >>>> 
>> >>>>   "web-banner":
>> >>>>     "This is *very sensitive* data.
>> >>>> 
>> >>>>      ![](mister-yuk.png)
>> >>>> 
>> >>>>      I'm serious, dude"
>> >>>> 
>> >>>> To be able to do this, it should be sufficient that the description of
>> >>>> the "web-banner" anyxml node states that HTML has to be used in XML
>> >>>> encoding and markdown in JSON.
>> >>>> 
>> >>>> Note that the -00 version of the draft contained a very similar example:
>> >>>> 
>> >>>> http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00#section-3.2.5
>> >>>> 
>> >>> 
>> >>> As technical contributor, I do not agree that an encoder is tasked to
>> >>> arbitrarily render XML content in the hope that the receiver likes the
>> >>> result.
>> >> 
>> >> It is not an arbitrary rendering, it is what the definition of the anyxml node demands - and both HTML and markdown are supposedly well-defined so that there is no guesswork involved. Both parties just follow the data model, nothing else.
>> >> 
>> > 
>> > How does your _encoder_ know the receiver wanted markdown? This idea
>> > is really broken and, as I said before, encoders are not translators
>> > that transform at their own will say XHTML into markdown.
>> 
>> My application knows whether it will send XML or JSON, so it prepares appropriate data (HTML or markdown) and calls the corresponding encoder.
>> 
>> It is still the same: you and Andy cater for the application model where the data are put into an intermediate “encoding-agnostic” structure from which it can be, as the very last step, serialised to either XML or JSON by a dumb encoder. But because the intermediate structure is the DOM or something like that, it isn’t in fact encoding-agnostic: it is pure XML, and that’s why you demand that JSON encoding follow the XML suit where possible.
>> 
>> If you start with an XML-only application, this may be a good strategy for adding JSON with minimal development effort, but I am strongly against “optimizing” the JSON encoding specifically for this model.
>>
>
> I am strongly against breaking layering abstractions. The code
> handling the data store operations should not do encoding specific
> stuff. This is a major layering violation. If we break layering for

There are two problems with this layering abstraction:

1. XML and JSON are not just encodings, their infosets are significantly
   different. Creating a layered abstraction thus necessarily means that
   either XML or JSON is chosen as primary and the other has to be
   coerced into looking the same. Hence the discussions about using only
   strings in JSON or, conversely, eliminating mixed content, comments
   and processing instructions in XML.

2. JSON APIs are very different from XML ones in that they are much
   closer to the native data structures of applications. Processing JSON
   in the same way as XML, except (de)serialisation, begs the question of
   what's the benefit of using JSON in the first place.

That said, I think much of this hairy discussion is really
moot. Instead, I'd love to hear concrete proposals for changing the text
in section 5.5 of the yang-json draft.

Lada

> JSON, we will have to break it again for CBOR and who knows what comes
> next. The result will be a mess. Please check who is speaking up on
> the list in favor of your interpretation of anyxml and who is having
> concerns with it.
>
> /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
-------------------- End of forwarded message --------------------

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Feb 2015 07:51:18 -0800

> in section 5.5 of the yang-json draft.

I have offered several specific mappings that attempt to utilize the common
features of both XML and JSON.

What use is JSON?  It is a more efficient encoding format. Period.

There seems to be a lot of confusion about who "owns" the schema.
It's always the server.  The client cannot give the server some
"poor man's schema" in the form of particular JSON encoding choices.
The server has no obligation whatsoever to pay any attention to
client schema hints.  YANG "anyxml" means no schema.  It does
not mean client-provided mini-schema.

> Lada

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 08 Feb 2015 16:59:59 +0100 (CET)

> What use is JSON?  It is a more efficient encoding format. Period.

For some definition of "efficient"...  uncompressed JSON produces
fewer bytes than uncompressed XML, but JSON requires the receiver to
buffer everything.

I think the main attraction of JSON is non-technical.  

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Feb 2015 08:10:01 -0800

> fewer bytes than uncompressed XML, but JSON requires the receiver to

good point.
JSON is also a nightmare for a server to stream compared to XML.

> I think the main attraction of JSON is non-technical.

I think the appeal is rapid-prototyping, and that works OK
except stay away from anyxml.  Using input without checking
it is never wise, but even worse when the data modeling language
is telling you "there is no schema for this data".

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 09 Feb 2015 09:41:11 +0100

> I think the main attraction of JSON is non-technical.

I disagree. It is actually the API that's the main attraction. For
example, look at Python:

>>> import json
>>> json.dumps(['foo', {'bar': ('baz', None, 1.0, 2)}])
'["foo", {"bar": ["baz", null, 1.0, 2]}]'

Compare this to XML where you have to set up additional structures or
callback functions. Libraries like libxml2 are relatively bulky and
still have gaps and problems.

BTW, my (technical) colleagues are now designing a new YAML-based
configuration format for the Knot DNS server, and a special remote
configuration protocol - despite the fact that I've been harassing them
with NETCONF and YANG for several years. And they refused NETCONF
specifically because of the fact it is limited to XML.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Tue, 10 Feb 2015 20:34:09 -0500

>specifically because of the fact it is limited to XML.

There's always a newer flavor-of-the-month.  The funny bit is when
the FOTM is celebrated because it's free of all the "cruft" of the
previous FOTM, but then the crowd starts immediately rebuilding
that cruft for the new FOTM.  See json-schema, json-pointer, etc.

It would be interesting to ask them with version of YAML they are
using, given that 1.2 is five years only, but yaml.org lists only
two implementations of it.  ;^)

And yes, xml definitely needs better libraries.  There's no reason
I can't parse XML into modern structures.  Take a look at pyez

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Feb 2015 09:01:04 +0100

> that cruft for the new FOTM.  See json-schema, json-pointer, etc.

We know that schemas and pointers are useful, right? :-) However, a
programmer with no knowledge of JSON whatsoever can start using it
effectively after maybe 20 minutes. It takes *much* longer with XML, and
you can run into surprises even after having used it for a long time.

One thing that makes XML really complex is the mixed content - it is
good for documents with markup but useless for hierarchical data.

> two implementations of it.  ;^)

I hope I will be able to convince them to go for JSON, that way we could
at least use YANG.

> I can't parse XML into modern structures.  Take a look at pyez

Actually, XML needed better libraries 15 or 20 years ago, and the
situation hasn't improved that much since then.

I think XML will continue to be used in areas like HTML where it makes
sense, but in the area of data storage and interchange it will be
outcompeted by simpler formats - it is already happening. That's why I
also think making XML the mandatory encoding for RESTCONF is, well,
unwise.

Lada