Hi -
Some lessons learned from annotating SMI files for code generation
are probably applicable here.
(1) doing annotations "in-line", regardless of the grammatical
tricks used to support those annotations, is problematic
from a software configuration management perspective.
(a) as new versions of the module definition appear,
it becomes necessary to "re-apply" annotations.
This is particularly a nuisance when different
organizations are involved.
(b) when the same module needs to be annotated in
different ways for different purposes, as when used
in multiple products built using different development
environments.
(2) As others have already mentioned, working within the
language framework for annotation syntax is a big win
*if* you're doing annotations in-line, but see (1).
Randy
-----Original Message-----
From: Vinod Kumar
Sent: Jul 1, 2016 6:21 AM
To: Martin Bjorklund
Cc: "[email protected]" , "Anil Kumar S N (VRP Network BL)" , Gaurav
Agarwal , [email protected]
Subject: Re: [netmod] Request to review the YANG compiler annotations draft.
Dear Martin,
Thanks for your valuable comments.
Initially we also wanted to define them as individual extensions and use
them in the YANG file as indicated by you.
Below are some reasons, which compelled us to add them as a separate
annotations(metadata) in YANG file.
- These extensions are not required while defining the schema, it is only
required while implementing a schema in a server or client. It is used by
applications to instruct the YANG utilities or compilers to automate the
application development related to data organization / processing. - These
extension are of internal scope, and should be masked while server advertises
its schema resources. - These extension values for a given YANG file may not
match in server and client.
We felt that annotating is a good option, similar to other languages
where-in by looking at annotation itself utilities/compilers can perform
additional functionality as instructed.
As you have pointed out, it is not a valid YANG 1.0, so we can modify it as
extensions to be compatible.
We feel that annotation (compiler) support in YANG is an important
requirement which needs to be standardized for all compiler implementation,
hence we believe there is a need to incorporate annotations in YANG 2.0.
Looking forward for your opinion/feedback.
Thanks and Regards,Vinod Kumar S.
On Fri, Jul 1, 2016 at 2:10 PM, Martin Bjorklund <[email protected]> wrote:
"vinods.kumar" <[email protected]> wrote:
> Dear All,
>
> We have written a draft, to add annotation in YANG definition which can
> be used by the YANG compilers.
>
> We are implementing these drafts as a reference implementation in the IETF
> 96 hackathon on ONOS YANG utilities.
>
> Request you to review the below drafts and provide your comments/feedback.
>
> Draft(s):
> https://datatracker.ietf.org/doc/draft-agv-netmod-yang-compiler-metadata/
>
>
> https://datatracker.ietf.org/doc/draft-agv-netmod-yang-annotation-ds-and-der
> ived/
I have looked at these drafts. I have two high-level comments.
1) What you propose is not valid YANG. This new syntax would
require a new version of the YANG language.
2) What you propose is not necessary; it can be done (and is being
done in several existing implementations) with current YANG
syntax and semantics, with normal YANG extension statements.
For example, the draft proposes this:
list server {
ca:compiler-annotation{
@MappedCollection(collection-type='map', map-key='name')
@OverrideImpl('DefaultServer');
}
...
It can be done today as:
list server {
xx:mapped-collection {
xx:collection-type map;
xx:map-key name;
}
xx:override-impl DefaultServer;
...
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
