So if I can continue to clarify the previous comment: given that YANG is an data modeling language, what benefit does it offer when compared with XSD which as been used/tested for many projects?
In my mind, there were two major things that influenced the final decision. First; we wanted it to be easily readable by humans first and foremost, as schemas are written once but read many times. Second; it needed to be able to separate between configuration and state data, and describe Remote Procedure Calls (RPCs) and notifications.
wrt your final decision: obviously, those aren't very compelling reasons. It would be simpler for you to say "We don't care about previous solutions. We're following the standardization track so that people can understand our design and provide comments/suggestions, but we're not going to justify our decision."
For example, the "easily readable" constraint is simply ridiculous because the most common format for data on the web is HTML which survives partly because it can be rendered in a format that is easy to read.
I meant to say "easily readable in it's native encoding". I.e. Looking at the source in your favourite text editor.
But I happen to personally think that a datalog- or lisp-based policy language for YANG-modelled data sources would be a very interesting concept.
That matches the structure of Lisp. Lisp code is basically set out as an AST. A Lisp node basically either contains a function and a list, or a function and simple value(s). The former can be thought of as a parent node, the latter can be thought of as a child node.
In my view Thrift is probably a better approach. Thrift files are still human readable and strongly typed. Since they are native C structs, there is no need for serialization. Those structs automatically show up as objects in something like Python. With Yang there's all this middle code that people use that is not doing anything but mapping the Yang data model to objects. Seems to be that this adds a lot of unnecessary bloat and the potential for lots of buggy behavior.
I personally and currently believe we need more context-specific language features for network management than what is available out of the box in Thrift. E.g. I think having the concepts of "configuration", "state data", "rpcs" as first class entities in the language itself is of great value. On the other hand, I can see the value of tool reuse in shops that have invested heavily in Thrift (or grpc/protocol buffers).
I also don't think we need the type of middle-code that you mention, and that's just the side effect of immature implementations. Always avoid intermediary steps if at all possible.