Juergen Schoenwaelder <[email protected]> wrote:
> On Wed, Oct 01, 2014 at 03:23:49PM -0400, Y. Richard Yang wrote:
> > On Wed, Oct 1, 2014 at 3:08 AM, Juergen Schoenwaelder <
> > [email protected]> wrote:
> >
> > > On Tue, Sep 30, 2014 at 04:31:03PM -0400, Y. Richard Yang wrote:
> > >
> > > > A particular example of using key-value map is the network-map, which is
> > > > defined as a key-value store to enforce that each named endpoint address
> > > > group has a unique name. A specific example is in Section 11.2.1.7 of
> > > > RFC
> > > > 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt):
> > > >
> > > > "network-map" : {
> > > > "PID1" : {
> > > > "ipv4" : [
> > > > "192.0.2.0/24",
> > > > "198.51.100.0/25"
> > > > ]
> > > > },
> > > > "PID2" : {
> > > > "ipv4" : [
> > > > "198.51.100.128/25"
> > > > ]
> > > > },
> > > > "PID3" : {
> > > > "ipv4" : [
> > > > "0.0.0.0/0"
> > > > ],
> > > > "ipv6" : [
> > > > "::/0"
> > > > ]
> > > > }
> > >
> > > Since YANG's native encoding is XML, how would you represent this in
> > > XML with the restriction that XML element names are defined by the
> > > data model and all values are in XML elements?
> > >
> >
> > Would you consider this as a limitation of the restriction?
> >
> > With the restriction, if we have the YANG data type to introduce key-value
> > store, for XML, the Mapping Rule may still be that of using two elements
> > with name and value: pid-name = (or just key as name), pid-value = (or
> > value). But for json and languages that support maps, the mapping does not.
> > Make sense?
> >
>
> I am saying that YANG was designed to model data carried by NETCONF
> (check the title of RFC 6020) and NETCONF uses XML as its data
> encoding with a set of restrictions that were found useful to simplify
> things (all data in XML elements, no mixed content, ...). Several
> details of the YANG language are related to XML (e.g., much of the
> type system, the usage of xpath in must/when expressions, instance
> identifier as a subset of xpath, ...).
>
> Alternate _encodings_ are proposed (such as JSON) but the question
> raised here seems to be whether we want to start an effort to turn
> YANG into a schema language for JSON (which it is not today and this
> is by design and not by accident).
I think the question is if it would be a good idea to add a "map"
keyword to YANG. Then, if we have "map", we can decide how to encode
it in XML and JSON.
For the record, I do not think we should add this. I am not sure when
it is a good idea to model an open-ended map (i.e., with keys that are
not formally defined). In many cases I think it is better with
something like:
list my-map {
key "key";
leaf key {
type identityref { ... } // this means all keys are
// formally defined in YANG
}
leaf value {
type string;
}
}
/martin
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
