Re: [netmod] metadata in JSON

[Ladislav Lhotka <[e-mail]>]

On 26 Aug 2014, at 15:19, Martin Bjorklund <[e-mail]> wrote:

> 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).

Hmm, do you mean that the set of attributes allowed in (a given version of) RESTCONF will be fixed and no other attributes can be used? In this case we probably needn’t bother with attribute namespaces at all.

Lada

> 
> 
> /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

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