On 16/04/2018 17:07, Andy Bierman wrote:
On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
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.
It is not clunky that 2 top-level YANG data nodes in the same module
have unique names. This is simple and deterministic.
This restriction has not been a problem so far.
I agree with the statements above.
But it is not clear to me that yang-data-ext is really defining new top
level data nodes that are part of the same tree/namespace as the
configuration/state nodes. In Martin's examples they were used within
RPCs, and it the forcing the names to be unique in that context that I
think would be clunky. E.g. in Martin's example forcing different names
for "reason" and "user-info" doesn't seem to be helpful.
The yang-data statement has to define the context or new abstract
namespace,
or whatever this hack is called.
Perhaps. I think that this depends on how they are used.
Could a fix for this be something along the lines of:
- yang-data names must be unique amongst other top level data nodes
within the module.
- if yang-data extensions are used at the top level then their name
must be used as a single top level container.
- if a yang-data extension is used within another structure then the
yang-data name is excluded, and the top level nodes defined in the
yang-data definition are used ....
Every tool that implements yang-data has to be able
to interpret a yang-data statement exactly the same way.
If you want to reinvent XSD substitutionGroup, then do it right.
I'm not familiar with them. From a quick read, I don't see how they are
related to the problem that we are trying to solve here.
Thanks,
Rob
Thanks,
Rob
Andy
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.)
I see no reason to reinvent the grouping-stmt.
You could easily say opx:error-info-structure argument is a grouping name
as it is a yang-data name.
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 <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
