Re: [netmod] metadata in JSON

[Reinaldo Penno <[e-mail]>]

On 8/26/14 8:06 AM, Andy Bierman wrote:
>
>
>
> On Tue, Aug 26, 2014 at 7:47 AM, Reinaldo Penno <[e-mail] 
> <mailto:[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?

[RP] Because the metadata work for JSON is being done in the IETF

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

[RP] That should be true.

> The client won't be sending any requests with attributes unless
> it is programmed to understand specific attributes.

[RP] Yes...

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

[RP] Standards based attributes could be present in request or response 
without necessary a previous request, much like certain HTTP headers, or 
X-based HTTP headers. This goes back to my previous point about IANA 
registry.

>
> 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]
>>     <mailto:[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
>>         <http://example.com/ns/URI%7Dattr>": "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]
>>         <mailto:[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]
>>         <mailto:[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]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/netmod
>
>
>     _______________________________________________
>     netmod mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>
>