Hi,

this is a slippery slope. If we want to turn YANG into a general-purpose
schema language, it should IMO be done the other way around: design a
general-purpose schema language with a sound architecture, and then use
it for defining schemas of datastores, protocol messages or whatever.

YANG extensions make changes to the original YANG architecture way too
easy, but the result may be a bastard with no architecture at all.

Lada

Martin Bjorklund <m...@tail-f.com> writes:

> 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
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to