Subject: [netmod] Additional substatements in groupings

From: Balazs Lengyel <[email-masked]>
Date: Wed, 15 Oct 2008 10:37:44 +0200

Hello,
I wanted to use a grouping as a kind-of complex type. I ran into the problem that the list of 
substatements inside a grouping is rather limited.
Why can't we use the following statements directly under a grouping?
- key  (need it !!!)
- mandatory
- min-elements   (need it !!!)
- max-elements  (need it !!!)
- config
- type

Generally:
IMHO the main aim of a grouping is to be meaningful and correct ONCE IT HAS BEEN PUT INTO A USES.
Validation of a grouping itself should only complain about things, that can in no way be 
correct with any kind of uses statement. That means nearly all statements could be allowed 
inside a grouping with some exceptions e.g. module, submodule.

All the above statements can perfectly fulfill this requirement. E.g. the following examples 
make perfect sense for me:

grouping foo {
     key id;
     leaf id;
}

list myFooList {
    uses foo;
}

Or if a set of modules all reference the same set of other modules:

grouping commonImports {
    import yang-types {..}
    import inet-types {...}
    import ieee-types {...}
    import ericssonTypes {...}
    import ericssonExtensions {...}
    import tpsPlatformBaseStuff {...}		
}

module oneOfManyModules {
     uses commonImports;
}

Balazs
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Oct 2008 08:50:59 -0700

Balazs Lengyel wrote:
> Hello,
> I wanted to use a grouping as a kind-of complex type. I ran into the 
> problem that the list of substatements inside a grouping is rather limited.

I do not agree that this is useful, in relation to
the complexity and confusion that can result from
treating a grouping as a #define.

It impairs readability because important clauses
such as the 'key' get hidden, forcing the reader
to track down every grouping, look for 'uses' in that
grouping, track down that grouping, etc. -- just to
find out if a list has a key or not.

I prefer to keep groupings the way they are, as a collection
of data-def-stmts.

Andy

> Validation of a grouping itself should only complain about things, that 
> can in no way be correct with any kind of uses statement. That means 
> nearly all statements could be allowed inside a grouping with some 
> exceptions e.g. module, submodule.
> 
> All the above statements can perfectly fulfill this requirement. E.g. 
> the following examples make perfect sense for me:
> 
> grouping foo {
>     key id;
>     leaf id;
> }
> 
> list myFooList {
>    uses foo;
> }
>

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 15 Oct 2008 18:10:24 +0200

Hello,

> I prefer to keep groupings the way they are, as a collection
BALAZS: I think this is completely dependent on the modeling style you use.
Maybe "#define" is too strong wording especially considering prefixing issues, but  I still 
believe the substatements of grouping are extremely limited. We should allow key, 
max/min-elements, config etc.
If you use grouping as a kind of complex type, as we are forced to do, as our existing models 
need that, it is rather counter-intuitive to define a leaf in the grouping, but tell thats it 
is a key only in uses.
>> Validation of a grouping itself should only complain about things, 
>> that can in no way be correct with any kind of uses statement. That 
>> means nearly all statements could be allowed inside a grouping with 
>> some exceptions e.g. module, submodule.
>>
>>    import tpsPlatformBaseStuff {...}       }
>>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Oct 2008 11:22:20 -0700

Balazs Lengyel wrote:
> Maybe "#define" is too strong wording especially considering prefixing 
> issues, but  I still believe the substatements of grouping are extremely 
> limited. We should allow key, max/min-elements, config etc.
> If you use grouping as a kind of complex type, as we are forced to do, 
> as our existing models need that, it is rather counter-intuitive to 
> define a leaf in the grouping, but tell thats it is a key only in uses.
>>
>>

But YANG doesn't have complex types like XSD.
It is not object-oriented either.
IMO, features like this should be done with extensions,
because they make YANG too complicated to use for
many people.

BTW, you cannot change the key within a uses-stmt:

    refine-list-stmt       = list-keyword sep identifier-arg-str optsep
                          (";" /
                           "{" stmtsep
                              ;; these stmts can appear in any order
                              *(must-stmt stmtsep)
                              [config-stmt stmtsep]
                              [min-elements-stmt stmtsep]
                              [max-elements-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *(refinement-stmt stmtsep)
                           "}")

YANG is intentionally simple, especially wrt/ inline definitions
like list, container, and choice.  It is a long-standing IETF NM area
tradition to optimize for interoperability and readability,
over data modeling complexity.  SMIv2 is too simple, and now
YANG is getting too complicated.

Andy