Why netconf is not using XML as data modeling language?

Question

We know Netconf uses yang as data modeling language. Also it comprises of XML. Why XML itself is not used as modeling language?. What stops XML as a data modeling language?.

Answer 1

Note that NETCONF protocol related RFCs do not mandate any specific data model.

Data modeling and content issues are outside the scope of the NETCONF protocol. An assumption is made that the device's data model is well-known to the application and that both parties are aware of issues such as the layout, containment, keying, lookup, replacement, and management of the data, as well as any other constraints imposed by the data model.

NETCONF carries configuration data inside the element that is specific to the device's data model. The protocol treats the contents of that element as opaque data. The device uses capabilities to announce the set of data models that the device implements. The capability definition details the operation and constraints imposed by data model.

Devices and managers can support multiple data models, including both standard and proprietary data models.

RFC6241, Section 5.2

You should also note that YANG has an XML based format, called YIN, so technically it may be viewed as an XML based data modeling language as well.

A YANG module can be translated into an alternative XML-based syntax called YIN. The translated module is called a YIN module. This section describes bidirectional mapping rules between the two formats.

The YANG and YIN formats contain equivalent information using different notations. The YIN notation enables developers to represent YANG data models in XML and therefore use the rich set of XML-based tools for data filtering and validation, automated generation of code and documentation, and other tasks. Tools like XSLT or XML validators can be utilized.

The mapping between YANG and YIN does not modify the information content of the model. Comments and whitespace are not preserved.

RFC7950, Section 13

It is however true that YANG was initially designed with NETCONF in mind and is currently the preferred way to model data exchanged by peers in a NETCONF session.

Why not use existing XML based data models, such as XML Schema (XSD) and RelaxNG?

One of the arguments back then was readability. Readability by humans is a high priority goal for YANG - you should be able to implement a module by hardcoding everything, some modules actually require you to do that via normative text in descriptions of nodes. XML based data models are not very readable except for machines. I'll let you be the judge on whether YANG is more readable than XML, since that is completely subjective (you may test this by reading a module that is both in YANG and YIN format, side by side).

It is also much easier to achieve maximum interoperability (in other words, standardization) between peers with a more specific language, which YANG is. Imagine the mayhem of everyone using an abstract XML language, such as XSD. Everything is just elements and attributes as far as XSD is concerned - you cannot immediately tell whether a definition represents a notification, rpc, action or just plain data nodes. You'd have to rely on comments for such things. Of course someone else might use processing instructions for this. Or any other XML construct...

Answer 2

YANG is a data modeling language SPECIFICALLY defined for Network management (to model device data and operations). Whereas, XML is a general-purpose one. Refer to section 2.6 in RFC 3535 to understand the drawback of XML based Network management. Following is the list of Yang capabilities which suit Network management.

1. Filtering capabilities
2. Constraints to do automatic data validation
3. Syntax to define RPCs
4. Data types such as Leaf, Leaflist, etc which very well model a device data.

I do not agree to Predi response that "Note that NETCONF protocol related RFCs do not mandate any specific data model". IMO, Netconf uses one and only one data modeling language, that is Yang. What I understood from the RFC is that device OEM can either use a standard Yang based data-model or write a proprietary Yang based data-model. In the end, both the parties (device OEM and NMS developer) should agree to a common Yang based data-model.