Martin Bjorklund <m...@tail-f.com> writes:
> Aha, ok.  This description is not a correct description of the YANG
> data tree (in which XPath expressions etc are evaluated).  There is
> not a single "list node" called "interfaces".  Look at an example of
                                  ^ I'm pretty sure you mean "interface" here.
> an XML instance document:
>
>   <interfaces>
>     <interface>
>       <name>eth0</name>
>       ...
>     </interface>
>     <interface>
>       <name>eth1</name>
>       ...
>     </interface>
>   </interfaces>
>
> This also reflects the data tree.

OK, yes, I'm recalling that now.  I run into mental interference because
there are at least three ways of looking at it:

- The Yang statement is named "list" -- a singular noun -- and not
something like "repeated" or "repeated container".  And compared to
ordinary programming languages, the semantics is "array-of-structures".
(The fact that Yang doesn't orthogonalize the array and the structure is
why Yang must also have a leaf-list statement.)  So the "obvious"
semantics of the name is that it's "the name" of "the list".

- The XML version doesn't have an overt representation of the array, but
does have an overt representation of each structure and uses the list
name as the label of each structure.  The XPath expressions are
evaluated within this version, so the absence of an explicit array node
is important.

- The JSON representation overtly represents both the array ([...]) and
the structures ({...}), and applies the name to the array, not the
structures.  (Which means that you can't evaluate XPath expressions
directly against the JSON representation.)

Thus you get the contrasting representations:

   list bar {
     key foo;
     leaf foo {
       type uint8;
     }
     leaf baz {
       type string;
     }
   }

   <bar>
     <foo>123</foo>
     <baz>zig</baz>
   </bar>
   <bar>
     <baz>zag</baz>
     <foo>o</foo>
   </bar>

   "bar": [
     {
       "foo": 123,
       "baz": "zig"
     },
     {
       "baz": "zag",
       "foo": 0
     }
   ]

each of which invites one to speak of the schema in somewhat different
ways.

The way you'd describe a tree diagram differs depending on which way
you're looking at the schema.

Dale

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

Reply via email to