Don't groupings have a somewhat similar concern?
E.g. if two groupings define the same data node name and are used at
the same point then you would get a namespace clash, but YANG does not
disallow the groupings:
grouping foo_widget {
leaf name {
type string;
description "Name of my foo widget";
}
}
grouping bar_widget {
leaf name {
type string;
description "Name of my bar widget";
}
}
container all_widgets {
uses foo_widget;
uses bar_widget;
}
The principal difference here, is that the compiler can easily check and
reject the conflict at the uses statements.
Hence I think that it would be good if we could find a solution for
yang-data-ext that doesn't not require all root yang-data nodes to be
unique, since that feels somewhat clunky. I.e. my preference is to keep
them less restrictive, as Martin has proposed, if this is feasible.
Thanks,
Rob
On 16/04/2018 15:36, Andy Bierman wrote:
Hi,
I am strongly opposed to this change because it breaks the rule in
YANG 1.1
that there cannot be 2 sibling nodes defined in the same module namespace.
IMO since any yang-data nodes are ALLOWED to be used at the top-level,
then these top-level nodes cannot have conflicting names.
It is very important when parsing an instance document that the
instance data
can be associated with the correct schema. This is not possible if the
same top-level node has multiple yang-data nodes defined.
If one needs to define data that is not top-level, (1) use
augment-yang-data
or (2) use a different module.
Andy
On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund <m...@tail-f.com
<mailto:m...@tail-f.com>> wrote:
Hi,
While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
it is not clear what, if any, restrictions should be enforced for
yang-data structures. Even among the authors we have different ideas
for how this should work.
Background:
In 8040, the original yang-data extension had a restriction that said
that a yang-data structure MUST have exactly one container, since it
wouldn't be possible to have a yang-data structure in an XML instance
document otherwise.
Since people want to use yang-data structures in other places, this
restriction was lifted in the new draft:
There is no longer an assumption that a yang data structure can
only be used as a top-level abstraction, instead of nested within
some other data structure.
With this in mind, here's a use case that I think we ought to support:
rpc my-first-rpc {
description
"Bla bla...
If an error occurs, <error-info> will contain an instance of
the yang-data structure 'my-first-rpc-error-info'.";
...
}
yang-data my-first-rpc-error-info {
leaf reason { ... }
container user-info { ... }
}
rpc my-second-rpc {
description
"Bla bla...
If an error occurs, <error-info> will contain an instance of
the yang-data structure 'my-second-rpc-error-info'.";
...
}
yang-data my-second-rpc-error-info {
leaf reason { ... }
leaf important-url { ... }
}
(maybe in the future we could even have a YANG extension statement to
formalize the description:
rpc my-first-rpc {
...
opx:error-info-structure my-first-rpc-error-info;
}
but this is not point now.)
In the example above, note that the leaf "reason" is present in both
structures. IMO this is not a problem, since these structures are
used in different contexts.
My point is that I think we should impose as few restrictions as
possible to the yang-data extension. It should be up to the user of
yang-data to ensure that the structure is defined in such a way so
that it can be used properly. For example, a structure that is
supposed to describe an XML instance document cannot define two leafs
at the top level.
If the WG agrees with what I wrote above, we need to change the
augment-yang-data extension so that you would write for example:
yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
...
}
Comments?
/martin
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
