> People want to use YANG to define the schema for an XML or JSON
> representation of a stand-alone document.
Agreed
> The only data needed must be module + local-name.
Or maybe: module + local-name + context, where context is one of:
- data nodes
- RPC/actions
- notifications
- standalone artifacts (files)
At least, it seems that these are different things.
[Note: RESTCONF places some of the context into the URL; two different data
node resources can have identical module + local-name.]
It would be bad if two stand-alone artifacts had the same module+local-name
(foo:bar). However, it's okay to have a matching top-level data node called
"foo:bar", since it is used in a different context. Just like yang-data cannot
be accessed as data via a protocol like NC or RC, so it is that
traditionally-defined data nodes cannot be accessed as a stand-alone artifact
(unless you’re a draft-author and need an instance document for an example).
> Defining an extension that maps error-info data for a specific RPC might be
> something worth standardizing. It should not be done with yang-data,
> but rather a different extension just for this purpose.
Martin wrote before:
(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 imagined that he was hoping to limit what's needed to get
draft-ietf-netconf-notification-messages out the door now, but I think another
I-D should be proposed to augment the 'rpc' and 'action' statements with an
anydata called "error-info-structure" so the YANG would be more like this:
rpc my-first-rpc {
...
opx:error-info-structure my-first-rpc-error-info {
…
}
}
That is, to your point, with no reference to a yang-data data structure.
> Andy
Kent // contributor
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
