Re: [netmod] yang-json document

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

> On Thu, Feb 5, 2015 at 12:45 PM, Martin Bjorklund <[e-mail]> wrote:
>> Andy Bierman <[e-mail]> wrote:
>>> On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka <[e-mail]> wrote:
>>> >
>>> >> On 05 Feb 2015, at 13:52, Martin Bjorklund <[e-mail]> wrote:
>>> >>
>>> >> Ladislav Lhotka <[e-mail]> wrote:
>>> >>> Hi,
>>> >>>
>>> >>> $SUBJ is already several months late, so I think we should proceed
>>> >>> towards delivering it. I checked my mail archive since the -02
>>> >>> revision,
>>> >>> and it seems two issues need to be resolved:
>>> >>>
>>> >>> 1. Andy objected to making redundant namespace prefixes illegal. I
>>> >>>   propose the following change to 4th paragraph in sec. 4 (SHOULD NOT
>>> >>>   instead of MUST NOT):
>>> >>>
>>> >>>   OLD
>>> >>>
>>> >>>   Names with namespace identifiers in the form shown in Figure 1 MUST
>>> >>>   be used for all top-level YANG data nodes, and also for all nodes
>>> >>>   whose parent node belongs to a different namespace.  Otherwise, names
>>> >>>   with namespace identifiers MUST NOT be used.
>>> >>>
>>> >>>   NEW
>>> >>>
>>> >>>   Names with namespace identifiers in the form shown in Figure 1 MUST
>>> >>>   be used for all top-level YANG data nodes, and also for all nodes
>>> >>>   whose parent node belongs to a different namespace.  Otherwise, names
>>> >>>   with namespace identifiers SHOULD NOT be used.
>>> >>
>>> >> I don't think this is a good idea.  The reason is that it complicates
>>> >> both client and server code.  An implementation cannot write code like
>>> >> this:
>>> >>
>>> >>   name = interface['name']
>>> >>   mtu = interface['mtu']
>>> >>
>>> >> instead we have to look for both 'name' and 'ietf-interfaces:name':
>>> >>
>>> >>   if 'name' in interface:
>>> >>     name = interface['name']
>>> >>   else
>>> >>     name = interface['ietf-interfaces:name']
>>> >>
>>> >>
>>> >> One single deterministic encoding is simpler everywhere and less
>>> >> error-prone.
>>> >
>>> > I agree with you, this again makes standard JSON parsers (that give
>>> > you a pointer to the parsed structure) considerably less useful.
>>> >
>>>
>>> Customers are not following this rule and they never will.
>>> They avoid the problem by avoiding local-name conflicts
>>> in the first place. It is not user-friendly or CLI-friendly
>>> to allow sibling nodes to have the same local name.
>>> These are not open systems so controlling the module set
>>> is not a problem.
>>
>> But this is *another* issue.  Neither of the alternatives support this
>> use case.
>>
>>> >>> 2. anyxml encoding: although it is a misnomer, I propose to keep the
>>> >>>   current definition (sec. 5.5), i.e. allow any valid JSON value in
>>> >>>   JSON-encoded anyxml instances. I also think the text makes it
>>> >>>   sufficiently clear that no standard mapping between XML- and
>>> >>>   JSON-encoded instances is defined.
>>> >>
>>> >> Ok.
>>> >>
>>>
>>> I am not so sure ignoring XML is OK.
>>
>> So how would you encode an arbitrary XML snippet (which is what anyxml
>> is) in JSON?  I know you want to restrict anyxml, but that is simply
>> not how it is defined in 6020.  For now we have to live with that.
>>
>
> No -- the description-stmts for the anyxml nodes in YANG Patch
> specify the limitations and an implementation of ietf-yang-patch
> MUST support what it says.  If other individual YANG modules
> want to constrain anyxml in specific ways, they can do that.
> We can specify what an implementation of a particular module MUST
> accept.

Exactly! I think most, if not all, uses of anyxml and anydata will
assume some specific syntax and semantics (that needs to be explained in
the description). But this may also include a sensible, perhaps
non-trivial, way for mapping XML to JSON and back. And if there is no
sensible mapping, it is IMO also acceptable that certain uses of anyxml will
only be possible in XML encoding.

The point really is that there needn't be any common rules for all uses
of anyxml, except that it has to be well-formed for the given encoding. 

>
> XML has simple nodes which are empty and those which are not empty.
>
>   XML non-empty simple node <-->  JSON string
>   XML empty node <--> JSON null
>   XML complex node <--> JSON object
>
> No requirement to send arrays, boolean, or numbers, but MAY send,
> and MUST accept.  No requirement to preserve JSON type info.
> Must preserve xmlns and other attributes if QName or XPath content found.
> No XML PIs or mixed content allowed.
> IMO this will make XML <--> JSON translation work.
>
>
>
>>> There should be a warning that the JSON encoding the
>>> sender picks is not "sticky".  The receiver MAY change it
>>> to something else, such that if the original sender retrieves
>>> a new copy from the server, the JSON types might have changed.
>>>
>>> It is only safe to use the common features between XML and JSON.
>>
>> Right, and you get this from anydata!
>>
>
> Not as Lada defined his YANG to JSON mapping.

So far, anydata isn't covered at all.

Lada

>
>
>>
>> /martin
>
>
> Andy

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