Difference: YangTutorials (1 vs. 7)

Revision 72014-01-03 - MartinBjoerklund

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Changed:
<
<
See also YangDocuments.
>
>
See also Documents.
  DhcpTutorial serves as an introductory example of a simple YANG module. It models a subset of the configuration of a DHCP server.

DSDLMappingTutorial shows how to obtain RELAX NG, Schematron and DSRL schemas from YANG data models and how to validate instance XML documents with these schemas.

Added:
>
>
A guide to the development of a YANG module and corresponding instance data.
 
META FILEATTACHMENT attachment="tutorial-ietf71.ppt" attr="" comment="The tutorial presented at IETF 71 in Philly" date="1205187948" name="tutorial-ietf71.ppt" path="tutorial-ietf71.ppt" size="415232" stream="tutorial-ietf71.ppt" user="Main.MartinBjoerklund" version="2"

Revision 62013-09-04 - MartinBjoerklund

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Added:
>
>
See also YangDocuments.
 DhcpTutorial serves as an introductory example of a simple YANG module. It models a subset of the configuration of a DHCP server.

Revision 52010-05-27 - LadaLhotka

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Changed:
<
<
The DhcpTutorial serves as an introductory example of a simple YANG module. It models a subset of
>
>
DhcpTutorial serves as an introductory example of a simple YANG module. It models a subset of
 the configuration of a DHCP server.
Added:
>
>
DSDLMappingTutorial shows how to obtain RELAX NG, Schematron and DSRL schemas from YANG data models and how to validate instance XML documents with these schemas.
 
META FILEATTACHMENT attachment="tutorial-ietf71.ppt" attr="" comment="The tutorial presented at IETF 71 in Philly" date="1205187948" name="tutorial-ietf71.ppt" path="tutorial-ietf71.ppt" size="415232" stream="tutorial-ietf71.ppt" user="Main.MartinBjoerklund" version="2"

Revision 42008-03-10 - MartinBjoerklund

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
The DhcpTutorial serves as an introductory example of a simple YANG module. It models a subset of the configuration of a DHCP server. \ No newline at end of file
Added:
>
>
META FILEATTACHMENT attachment="tutorial-ietf71.ppt" attr="" comment="The tutorial presented at IETF 71 in Philly" date="1205187948" name="tutorial-ietf71.ppt" path="tutorial-ietf71.ppt" size="415232" stream="tutorial-ietf71.ppt" user="Main.MartinBjoerklund" version="2"

Revision 32007-11-19 - MartinBjoerklund

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
The DhcpTutorial serves as an introductory example of a simple YANG module. It models a subset of the configuration of a DHCP server.
Deleted:
<
<

Just like XSD (and NCX), the union member types are evaluated in the order specified. First match wins.

(FAQ will have a bit about putting the string pattern types before any generic string type in the union. Same for number types with range clauses and plain numbers.)


> Another issue with XSD is that their key mechanism doesn't mean the
> same as YANG's (in XSD the key constraint is used to guarantee that
> all nodes within the key set are unique within some element, and that
> all nodes must be present in an instance document). Further their
> keyref mechanism doesn't work the same way as YANG's. In YANG, keyref
> is used to reference any part of the configuration datastore. In XSD,
> a keyref can only be used to reference a key defined on the same
> level, or in an ancestor of the keyref.

Guys,

Just make sure this is captured in the doc or our FAQ...


We should have an example of local typedefs like this, although this is NOT correct: > typedef FooType? {
> type string;
> }
>
> grouping foo {
> leaf a { type FooType? ; }
> }
>
> container bar1 {
> uses foo;
> leaf b { type FooType? ; }
> }
>
> container bar2 {
> uses foo;
> typedef FooType? {
> type { uint64; }
> }
> leaf c { type FooType? ; }
> }
>
> Leaf 'bar1/a' is a string.
> Leaf 'bar1/b is a string.
> Leaf 'bar2/a' is a number.
> Leaf 'bar2/c' is a number.


> Andy Bierman <andy@andybierman.com> wrote:
>> Isn't there a scaling problem wrt/ the usage of lots of groups
>> within a module that grows over time? Group A is ok by itself,
>> Ditto for Group B. Both are defined externally to module 'foo',
>> which defines a container or list that uses A and B.
>> The name collision happens in the 3rd module, and the owner
>> of that module does not have change control over A and B.
>>
>> So you cut-and-paste either A or B and make a new group (A' or B')
>> instead? Yuch.
>>
>> On the other side, the price of name collision-free data modeling
>> is an extra XML layer. Yuch.
>
> So in the 3rd module you can introduce the container if needed. So
> instead of
>
> uses a:a;
> uses b:b;
>
> you do
>
> container a {
> uses a:a;
> }
> container b {
> uses a:a;
> }
>
>

I see, so the 3rd module uses containers cleanly to resolve the name collision. Perfect. (Save this for the HOWTO guide).

Revision 22007-11-13 - MartinBjoerklund

Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Changed:
<
<
We need a WEB-based tutorial that uses a simple but real example, like the ones for programming tools. There is one called "20 Minute Wiki" that shows how to build a wiki page using some Python tools.
>
>
The DhcpTutorial serves as an introductory example of a simple YANG module. It models a subset of the configuration of a DHCP server.
 

Revision 12007-11-02 - MartinBjoerklund

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="WebHome"
We need a WEB-based tutorial that uses a simple but real example, like the ones for programming tools. There is one called "20 Minute Wiki" that shows how to build a wiki page using some Python tools.


Just like XSD (and NCX), the union member types are evaluated in the order specified. First match wins.

(FAQ will have a bit about putting the string pattern types before any generic string type in the union. Same for number types with range clauses and plain numbers.)


> Another issue with XSD is that their key mechanism doesn't mean the
> same as YANG's (in XSD the key constraint is used to guarantee that
> all nodes within the key set are unique within some element, and that
> all nodes must be present in an instance document). Further their
> keyref mechanism doesn't work the same way as YANG's. In YANG, keyref
> is used to reference any part of the configuration datastore. In XSD,
> a keyref can only be used to reference a key defined on the same
> level, or in an ancestor of the keyref.

Guys,

Just make sure this is captured in the doc or our FAQ...


We should have an example of local typedefs like this, although this is NOT correct: > typedef FooType? {
> type string;
> }
>
> grouping foo {
> leaf a { type FooType? ; }
> }
>
> container bar1 {
> uses foo;
> leaf b { type FooType? ; }
> }
>
> container bar2 {
> uses foo;
> typedef FooType? {
> type { uint64; }
> }
> leaf c { type FooType? ; }
> }
>
> Leaf 'bar1/a' is a string.
> Leaf 'bar1/b is a string.
> Leaf 'bar2/a' is a number.
> Leaf 'bar2/c' is a number.


> Andy Bierman <andy@andybierman.com> wrote:
>> Isn't there a scaling problem wrt/ the usage of lots of groups
>> within a module that grows over time? Group A is ok by itself,
>> Ditto for Group B. Both are defined externally to module 'foo',
>> which defines a container or list that uses A and B.
>> The name collision happens in the 3rd module, and the owner
>> of that module does not have change control over A and B.
>>
>> So you cut-and-paste either A or B and make a new group (A' or B')
>> instead? Yuch.
>>
>> On the other side, the price of name collision-free data modeling
>> is an extra XML layer. Yuch.
>
> So in the 3rd module you can introduce the container if needed. So
> instead of
>
> uses a:a;
> uses b:b;
>
> you do
>
> container a {
> uses a:a;
> }
> container b {
> uses a:a;
> }
>
>

I see, so the 3rd module uses containers cleanly to resolve the name collision. Perfect. (Save this for the HOWTO guide).

 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback