Re: [netmod] metadata in JSON

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.

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.

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 <lhotka@nic.cz 
> <mailto:lhotka@nic.cz>> 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 <j.schoenwaelder@jacobs-university.de
>     <mailto:j.schoenwaelder@jacobs-university.de>> writes:
>
>     > On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote:
>     >>
>     >> On 31 Jul 2014, at 07:52, Juergen Schoenwaelder
>     <j.schoenwaelder@jacobs-university.de
>     <mailto:j.schoenwaelder@jacobs-university.de>> 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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>     > Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
>     --
>     Ladislav Lhotka, CZ.NIC Labs
>     PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod