Date: Thu, 05 Feb 2015 13:52:10 +0100 (CET)
Message-Id: <20150205.135210.818152609244122122.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <m2bnlh7emw.fsf@birdie.labs.nic.cz>
References: <m2bnlh7emw.fsf@birdie.labs.nic.cz>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/mCtvup_YnL3gvr95EIe4sSFcKfs>
Cc: netmod@ietf.org
Subject: Re: [netmod] yang-json document
Precedence: list

Ladislav Lhotka <lhotka@nic.cz> 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 revisi=
on,
> 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.=A04 (SHOULD =
NOT
>    instead of MUST NOT):
> =

>    OLD
> =

>    Names with namespace identifiers in the form shown in Figure 1 MUS=
T
>    be used for all top-level YANG data nodes, and also for all nodes
>    whose parent node belongs to a different namespace.  Otherwise, na=
mes
>    with namespace identifiers MUST NOT be used.
> =

>    NEW
> =

>    Names with namespace identifiers in the form shown in Figure 1 MUS=
T
>    be used for all top-level YANG data nodes, and also for all nodes
>    whose parent node belongs to a different namespace.  Otherwise, na=
mes
>    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 =3D interface['name']
   mtu =3D interface['mtu']

instead we have to look for both 'name' and 'ietf-interfaces:name':

   if 'name' in interface:
     name =3D interface['name']
   else
     name =3D interface['ietf-interfaces:name']


One single deterministic encoding is simpler everywhere and less
error-prone.
  =

> 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.


/martin