> On 21 Mar 2017, at 12:50, Robert Wilton <[email protected]> wrote:
>
>
>
> On 21/03/2017 10:49, Ladislav Lhotka wrote:
>>> On 21 Mar 2017, at 11:25, Juergen Schoenwaelder
>>> <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> if we want to standardize tree diagrams, we may want to take a more
>>> critical look at them, in particular the flags (that were created
>>> ad-hoc and in resemblance to MIB tree diagrams). pyang --tree-help
>>> says:
>>>
>>> <flags> is one of:
>>> rw for configuration data
>>> ro for non-configuration data
>>> -x for rpcs and actions
>>> -n for notifications
>>>
>>> This is (a) incomlete and (b) somewhat confusing since ct does not
>>> equate to readwrite. I am attaching a sample yang file and here is the
>>> output pyang 1.7.1 produces:
>>>
>>> module: tree-sample
>>> +--rw config-true-container
>>> | +--rw param? string
>>> +--ro config-false-container
>>> | +--ro value? string
>>> +--rw inline-action
>>> | +---x action
>>> | +---- oops? string
>>> | +---w input
>>> | | +---w in? string
>>> | +--ro output
>>> | +--ro out? string
>>> +--rw inline-notification
>>> +---n notification
>>> +---- duration? string
>>>
>>> rpcs:
>>> +---x rpc
>>> +---w input
>>> | +---w in? string
>>> +--ro output
>>> | +--ro out? string
>>> +--ro oops? string
>>>
>>> notifications:
>>> +---n notification
>>> +--ro boom? string
>>>
>>> I think a better usage of two letter flags would have been this (since
>>> it more naturally aligns with what the YANG definition says):
>>>
>>> <flags> is one of:
>>> ct for configuration data
>>> cf for non-configuration data
>>> x- for rpcs and actions
>>> xi for rpc or action input
>>> xo for rpc or action output
>>> n- for notifications
>>> nt for notification tree (this is I think the term 7950 uses)
>> Inside notifications and operations, "cf" carries no information and just
>> clutters the output. My suggestion is to use "ct" or just "c" for
>> config=true data and nothing elsewhere.
> Do, we also actually need the 'xi', 'xo', or 'nt' at all? Would these be
> obvious from the paths anyway?
Yes, "input" and "output" tells everything.
>
> I think that having less symbols on the diagram may make it easier to parse,
> and perhaps less likely for the lines to wrap.
+1
>
> So I am suggesting perhaps just having:
>
> <flags> is one of:
> c for configuration data
> x for rpcs and actions
> n for notifications
>
> module: tree-sample
> +--c config-true-container
> | +--c param? string
> +--- config-false-container
> | +-- value? string
> +--c inline-action
> | +--x- action
> | +--x input
> | | +--x in? string
> | +--x output
> | +--x out? string
> +--c inline-notification
> +--n notification
> +--n duration? string
>
I think the "x" and "n" is only needed next to the name of
rpc/action/notification. So my version would be:
<flags> is one of:
c for configuration data
x for rpcs and actions
n for notifications
module: tree-sample
+--c config-true-container
| +--c param? string
+--- config-false-container
| +--- value? string
+--c inline-action
| +--x action
| +--- input
| | +--- in? string
| +--- output
| +--- out? string
+--c inline-notification
+--n notification
+--- duration? string
Lada
> etc.
>
> Rob
>
>
>>
>> Lada
>>
>>> module: tree-sample
>>> +--ct config-true-container
>>> | +--ct param? string
>>> +--cf config-false-container
>>> | +--cf value? string
>>> +--ct inline-action
>>> | +--x- action
>>> | +--xi input
>>> | | +--xi in? string
>>> | +--xo output
>>> | +--xo out? string
>>> +--ct inline-notification
>>> +--n- notification
>>> +--nt duration? string
>>>
>>> rpcs:
>>> +--x- rpc
>>> +--xi input
>>> | +--xi in? string
>>> +--ro output
>>> +--xo out? string
>>>
>>> notifications:
>>> +--n- notification
>>> +--nt boom? string
>>>
>>> (And I think the oops leafs should have triggered an error.)
>>>
>>> /js
>>>
>>> --
>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>>> <tree-sample.yang>_______________________________________________
>>> netmod mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
