"Acee Lindem (acee)" <[email protected]> wrote:
> Martin, Lada, et al,
>
> While I don’t think we need additional annotations that Joe had prototyped
> (at least not as the default), I strongly believe we need to keep the ‘@‘
> and ‘/‘ in the tree output for schema mount.
Can you explain what information "/" gives the reader? Compare these
two trees:
+--mp vrf-root
+--rw rt:routing/
+--rw rt:router-id
and
+--mp vrf-root
+--rw rt:routing
+--rw rt:router-id
What did the "/" in the first tree tell me that I don't see in the
second tree?
Then consider:
+--ro if:interfaces@
and
+--ro if:interfaces
+-- if:interface@
and
+--ro if:interfaces@
+-- if:interface@
Which ones are legal, and what do they mean?
/martin
While the former enhancement
> provided details, the schema mount tree designations are every bit as
> important as knowing, for example, whether or not a schema leaf is a
> presence node.
>
> Thanks,
> Acee
>
>
> On 9/15/17, 9:56 AM, "Acee Lindem (acee)" <[email protected]> wrote:
>
> >+1 - Also it is hard enough to format the tree output to fit in a draft
> >w/o further annotations (even with —-tree-line-length).
> >Thanks,
> >Acee
> >
> >
> >On 9/15/17, 6:21 AM, "netmod on behalf of Ladislav Lhotka"
> ><[email protected] on behalf of [email protected]> wrote:
> >
> >>Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
> >>> Hi,
> >>>
> >>>
> >>> Actually I liked the early pyang output that was concise and easy to
> >>>remember.
> >>> The current format gets very cluttered and there are too many little
> >>>symbols
> >>> to remember them all.
> >>
> >>I agree.
> >>
> >>Lada
> >>
> >>>
> >>>
> >>> Andy
> >>>
> >>>
> >>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke <[email protected]> wrote:
> >>> > I've been hacking on pyang, and I changed tree.py to add the enum
> >>>values
> >>> > for enumeration types and identiyref bases for identityref types.
> >>>Here
> >>> > is an example:
> >>> >
> >>> > module: yang-catalog
> >>> > +--rw catalog
> >>> > +--rw modules
> >>> > | +--rw module* [name revision organization]
> >>> > | +--rw name yang:yang-identifier
> >>> > | +--rw revision union
> >>> > | +--rw organization string
> >>> > | +--rw ietf
> >>> > | | +--rw ietf-wg? string
> >>> > | +--rw namespace inet:uri
> >>> > | +--rw schema? inet:uri
> >>> > | +--rw generated-from? enumeration [mib, code,
> >>> > not-applicable, native]
> >>> > | +--rw maturity-level? enumeration [ratified,
> >>> > adopted, initial, not-applicable]
> >>> > ...
> >>> > +--rw protocols
> >>> > | +--rw protocol* [name]
> >>> > | +--rw name
> >>> > identityref -> protocol
> >>> > ...
> >>> >
> >>> > My questions are:
> >>> >
> >>> > 1. Is this useful?
> >>> >
> >>> > 2. If so, can this be added to pyang (happy to submit a PR) and
> >>> > draft-ietf-netmod-yang-tree-diagrams?
> >>> >
> >>> > 3. What changes to the output format would you recommend?
> >>> >
> >>> > Thanks.
> >>> >
> >>> > Joe
> >>> >
> >>> > _______________________________________________
> >>> > netmod mailing list
> >>> > [email protected]
> >>> > https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> [email protected]
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >>--
> >>Ladislav Lhotka
> >>Head, CZ.NIC Labs
> >>PGP Key ID: 0xB8F92B08A9F76C67
> >>
> >>_______________________________________________
> >>netmod mailing list
> >>[email protected]
> >>https://www.ietf.org/mailman/listinfo/netmod
> >
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
