Re: [netmod] metadata in JSON

[Andy Bierman <[e-mail]>]

On Tue, Aug 26, 2014 at 7:47 AM, Reinaldo Penno <[e-mail]> wrote:

>  I agree that vendors could define metadata as long as there is a
> procedure for that such as a IETF document and a IANA registry.
>
>
We don't need this for XML. Why do we need it for JSON?



> My reasoning is that I see this metadata is much like decorators in Java.
> In the case of JAVA<->JSON there are multiple libraries that can do
> serialization and they use different decorators, therefore not very
> interoperable. So, we I would suggest metadata/decorators are registered
> somewhere and there is possibility for standard, experimental and private
> notations.
>
>
The client parser does not need to understand the semantics of an attribute
in order to be able
to parse it in a reply.   The client won't be sending any requests with
attributes unless
it is programmed to understand specific attributes.

I see JSON attributes being used the same way XML attributes are being used
now
to represent meta-data associated with datastores.  (with-defaults,
enabled, etc.)
If the feature is designed correctly, then it won't break clients that don't
know about the attribute (client has to ask in the request for certain
attributes
to be present in the reply).

I don't see how Java programming practices impact the operational
requirements for datastores.
Vendors are going to use datastore meta-data whether the standard supports
it or not.


Andy


On 8/26/14 7:19 AM, Andy Bierman wrote:
>
> 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
>>
>
>
>
> _______________________________________________
> netmod mailing [e-mail]://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>