Re: [netmod] metadata in JSON

[Andy Bierman <[e-mail]>]

Hi,

This issue and been opened and closed again at least 3 times.
Are we spinning on this issue until you get the answer you like?
Which choice is the solution from Martin we already agreed to use?
That is the one I prefer.   The namespace URI is much longer than
the module-name, and not easy to remember like the module name.
But if YANG will not have attributes, then there may be no other choice.

I do not agree with the CLR that only the RESTCONF protocol doc
can define meta-data.  What is the purpose of that rule?  NETCONF
has "with-defaults" in a separate document.  The protocol
needs to be modular so new optional features can be added over time.
Vendors should be able to add meta-data as well.


Andy


On Tue, Aug 26, 2014 at 6:05 AM, Ladislav Lhotka <[e-mail]> wrote:

> Hi,
>
> I would like to resolve the issue of metadata encoding in JSON, so let
> me summarize the options we have. There are actually two valid questions:
>
> 1. Does the specification of the mapping of XML attributes in JSON
>    belong to the yang-json document, and if so, in what form?
>
> Possible answers:
>
> 1.1. No, as YANG doesn't model XML attributes.
> 1.2. Yes, as normative text.
> 1.3. Yes, as non-normative text.
>
> For 1.2 and 1.3, we have to answer the second question because I assume
> most XML attributes in use with YANG-modelled data will have non-null
> namespace:
>
> 2. How do we represent the namespace of an attribute in JSON?
>
> Possible answers, using
>
>   <elem xmlns:x="http://example.com/ns/URI" x:attr="foo">bar</elem>
>
> as an example:
>
> 2.1. Use Clark's notation [1]:
>
>   "elem": "bar",
>   "@elem": {
>     "{http://example.com/ns/URI}attr": "foo"
>   }
>
> 2.2. Associate somehow every attribute with a YANG module, and then use
>      the same notation as for encoding the namespace of YANG data nodes:
>
>   "elem": "bar",
>   "@elem": {
>     "somemodule:attr": "foo"
>   }
>
> 2.3. Associate somehow the XML namespace URI with a prefix in JSON and
>      then use the same notation as for XML:
>
>   "elem": "bar",
>   "@elem": {
>     "x:attr": "foo"
>   }
>
> In both 2.2 and 2.3, we need to say what "somehow" actually means. If we
> accept 1.3, it could I guess involve a certain amount of hand-waving but
> leaving it completely unanswered IMO makes the whole thing useless.
>
> I personally think that 2.3 would be a step in a wrong direction because
> the URI-prefix duality was recognized as a serious problem of XML
> namespaces [2].
>
> Please indicate your preferences or propose something else.
>
> Thanks, Lada
>
> [1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00
> [2] http://blog.jclark.com/2010/01/xml-namespaces.html
>
> Juergen Schoenwaelder <[e-mail]> writes:
>
> > On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote:
> >>
> >> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder <
> [e-mail]> wrote:
> >>
> >> > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote:
> >> >>
> >> >>>>> understand that this makes the solution somewhat incomplete but it
> >> >>>>> allows us to finish this document now and to move forward.
> >> >>>>
> >> >>>> That is my priority, too.
> >> >>>
> >> >>> Good. So what speaks against saying that if attribute names clash
> and
> >> >>> if attributes are scoped by a module name, then the encoding is XYZ?
> >> >>
> >> >> I thought YANG 1.1 was a good opportunity to decide about how to do
> this scoping, provided that standard attributes are really needed.
> >> >>
> >> >
> >> > Lets keep the discussion focused on the JSON document. Are you OK with
> >> > the proposal to add text that attribute names may be scoped?
> >>
> >> Yes, if there is no other choice. It is unclear what "scoped" means.
> >>
> >
> > Scoped by a namespace, such as 'namespace:identifier'.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> > Fax:   [phone]         <http://www.jacobs-university.de/>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>