Re: [netmod] metadata in JSON

[Martin Bjorklund <[e-mail]>]

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.

1.2

> 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"
>   }

2.1

And I think the text should specify that the usage of this meta data
must be defined by a specification that uses this mapping.  This means
that RESTCONF must specify which attributes are supported in RESTCONF,
and how they are encoded (i.e. if they have a namespace or not).


/martin



> 
> 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
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod