Differentiate between empty and boolean nodes

[timmartin]

I'm trying to write some serialisation code to output Netconf XML. My problem is that when examining a node I can't tell whether it's empty or boolean. For example in the test case boolean-empty.yang:

    container container {
        leaf b1 {
            type boolean;
            description
                "A test leaf";
        }

        leaf b2 {
            type boolean;
            default "false";
            description
                "A test leaf with a default";
        }

        leaf e1 {
            type empty;
            description
                "A test empty leaf";
        }
    }

t.container.b1 and t.container.e1 seem to look and act identically to my code, but I need to differentiate them in order to generate valid XML.

I can see how I could add another metadata field to the YangDynType for this, but I want to make sure I'm not missing some way of differentiating these cases using the information that's already available.

[robshakir]

Hi Tim,

Sorry -- I've been travelling for the last couple of days.

There is a _yang_type element in YANGDynType already - which stores what the leaf was defined as in the model. This would let you get the boolean vs. empty. There are nuances here, such that this may not work in all cases - for example, in the case that you have a typedef that then is a boolean or empty underneath, then this would not be exposed.

The best fix for this (it doesn't matter in other serialisations), would be to add something to YANGBool that is taken by the __init__ there to store whether it is being initialised as an empty or boolean leaf. This is then resilient to typedef features.

Would you be interested in contributing the XML serialisation code back into the project? :-)

Thanks,
r.

[timmartin]

Yes, _yang_type gives me what I need. It's not present in the version I'm using in production at the moment, and I forgot to check the most recent version.

In principle, I'd be happy to contribute the XML serialisation code. It probably doesn't cover all the cases at the moment as I've only tested with my own use cases, but hopefully it's a basis to start from. I'll have to check with my employer about the copyright situation, but I don't anticipate that will be a problem.