Hi Michal,
It is not the printing of the data that makes it valid/invalid.
I don't think that your input data was ever valid, because "container C"
doesn't satisfy the mandatory statement because it isn't a real data node in
the tree - it is instantiated when required and may be deleted when it is no
longer required.
I.e. your model has been designed such that it can never be satisfied.
If your model was instead:
container TOP {
leaf L {
type empty;
}
choice A {
mandatory true;
container C {
leaf L2 {
type empty;
}
}
}
}
Then this data is valid:
<TOP>
<L/>
<C>
<L2/>
</C>
</TOP>
But this data is not:
<TOP>
<L/>
</TOP>
Nor is this, which is directly equivalent to the one above, because the <C/>
container doesn't really exist if it doesn't have a child node present.
<TOP>
<L/>
<C/>
</TOP>
Thanks,
Rob
> -----Original Message-----
> From: Michal Vaško <[email protected]>
> Sent: 24 June 2019 18:15
> To: Andy Bierman <[email protected]>
> Cc: Rob Wilton (rwilton) <[email protected]>; netmod <[email protected]>
> Subject: Re: [netmod] ?= mandatory choice with non-presence container cas
>
> Hi Andy,
>
> On Monday, June 24, 2019 19:11 CEST, Andy Bierman <[email protected]>
> wrote:
>
> > On Mon, Jun 24, 2019 at 10:01 AM Michal Vaško <[email protected]> wrote:
> >
> > > Hi Rob,
> > > I think there is a problem in the RFC because using only allowed
> > > steps I got invalid data from initially valid data. That cannot be
> correct.
> > >
> > >
> > No. See sec. 7.5.7
> >
> > If a non-presence container does not have any child nodes, the
> > container may or may not be present in the XML encoding.
> >
> >
> > Just because your retrieval does not contain the NP-container, that
> > does not mean the NP-container was not present in the server for the
> > mandatory-stmt validation.
>
> I agree, but these valid data were correctly printed into invalid data. I
> do not think printing is allowed to change the validity of data.
>
> Michal
>
> >
> > Regards,
> > > Michal
> > >
> > >
> > Andy
> >
> >
> > > On Monday, June 24, 2019 18:52 CEST, "Rob Wilton (rwilton)" <
> > > [email protected]> wrote:
> > >
> > > > Hi Michal,
> > > >
> > > > My thoughts:
> > > >
> > > > According to 7.5.1:
> > > >
> > > > In the first style, the container has no meaning of its own,
> existing
> > > > only to contain child nodes. In particular, the presence of the
> > > > container node with no child nodes is semantically equivalent to
> the
> > > > absence of the container node. YANG calls this style a "non-
> presence
> > > > container". This is the default style.
> > > >
> > > > Hence your request (because the NP container does not have any
> > > > children)
> > > is equivalent to:
> > > >
> > > > <TOP>
> > > > <L/>
> > > > </TOP>
> > > >
> > > > which fails the "mandatory" check.
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: netmod <[email protected]> On Behalf Of Michal Vaško
> > > > > Sent: 24 June 2019 17:39
> > > > > To: netmod <[email protected]>
> > > > > Subject: [netmod] mandatory choice with non-presence container
> > > > > case
> > > > >
> > > > > Hi,
> > > > > I have encountered a situation that I think is not covered by
> > > > > RFC
> > > 7950. My
> > > > > specific use-case was as follows.
> > > > >
> > > > > model:
> > > > >
> > > > > container TOP {
> > > > > leaf L {
> > > > > type empty;
> > > > > }
> > > > > choice A {
> > > > > mandatory true;
> > > > > container C;
> > > > > }
> > > > > }
> > > > >
> > > > > data:
> > > > >
> > > > > <TOP>
> > > > > <L/>
> > > > > <C/>
> > > > > </TOP>
> > > > >
> > > > > Parsing was successful, but printing these data back to XML
> produced:
> > > > >
> > > > > <TOP>
> > > > > <L/>
> > > > > </TOP>
> > > > >
> > > > > and parsing this correctly failed with missing mandatory choice.
> > > According
> > > > > to section 7.5.7 [1], I think the C container could be omitted
> > > > > but the whole situation does not seem correct. Thank you for any
> input.
> > > > >
> > > > > Regards,
> > > > > Michal
> > > > >
> > > > > [1] https://tools.ietf.org/html/rfc7950#section-7.5.7
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > [email protected]
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
