4 ms·

On first glance this seems to be JSON with stronger typing. Is that a fair assessment?

geezerjay 10y ago
I haven't read it thoroughly but it appears that YANG is way more than that. It also supports schemas, declares data in a modular way, impose data constraints, and of course strong typing. It is, however, absurdly complex compared with JSON.
- sametmax 10y ago
  So a less supported/powerful/tested XML.
  - camoberg 10y ago
    It's a schema language, not a general data encoding language. Widely used for NETCONF[1] and RESTCONF[2]. 1. https://tools.ietf.org/html/rfc6241 https://tools.ietf.org/html/rfc6241 2. https://tools.ietf.org/html/draft-ietf-netconf-restconf-18 https://tools.ietf.org/html/draft-ietf-netconf-restconf-18)
    - keithb- 10y ago
      To be fair, I think that previous comment was implying the constellation of XML technologies e.g. XSD, XPath. XML encoding is rarely used in isolation because, honestly, what's the point? Sure, your document is well-formed, but you could achieve the same thing with tab+carriage return. 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?
      - camoberg 10y ago
        YANG has a distinctly different purpose. XSD, RelaxNG, and some other alternatives were considered during the development of what eventually became YANG back in 2007. We spent quite a bit of time with XML grey beards on this topic in the IETF, and eventually realized that YANG had too many domain specific requirements that it wasn't worth trying to bend existing languages for it. 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.
        sametmax 10y ago
        So like SOAP and XMPP ?
        keithb- 10y ago
        Thank you for clarifying. 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.
        darfs 10y ago
        I would add the Point that XML is _the_ readable format. Just only because the seperations and nearly there is no trick-shit-thing(e.g. as in Rust, Go, C, JS, ...(that's nothing what i want to blame some language for, but seriously, nearly any language has some Tricks with it's Syntax))
        camoberg 10y ago
        Well, I would say that we did spend considerable time and energy among peoole with vast experience from designing various kinds of languages before we ended up going down the path towards what became YANG. If you poke around the IETF mailing list archives I think you will find ample amounts of justification before we were given the green light from the IAB. I meant to say "easily readable in it's native encoding". I.e. Looking at the source in your favourite text editor.
        ZenoArrow 10y ago
        Thanks for the clarification. Out of interest, did you evaluate building a Lisp DSL? If so, any pros and cons you identified from that approach? I would've thought it would have been a quicker option to get going, though if you've reached version 1 you've put in the groundwork required now.
madgar 10y ago
Your first glance may have missed that the first sentence of the RFC says it includes modeling for "Remote Procedure Calls" and "notifications for network management protocols." Your first glance may have also missed that the RFC is nearly 200 pages. Given those details, would you re-evaluate your guess?

I haven't read it thoroughly but it appears that YANG is way more than that. It also supports schemas, declares data in a modular way, impose data constraints, and of course strong typing. It is, however, absurdly complex compared with JSON.

sametmax 10y ago
So a less supported/powerful/tested XML.
- camoberg 10y ago
  It's a schema language, not a general data encoding language. Widely used for NETCONF[1] and RESTCONF[2]. 1. https://tools.ietf.org/html/rfc6241 https://tools.ietf.org/html/rfc6241 2. https://tools.ietf.org/html/draft-ietf-netconf-restconf-18 https://tools.ietf.org/html/draft-ietf-netconf-restconf-18)
  - keithb- 10y ago
    To be fair, I think that previous comment was implying the constellation of XML technologies e.g. XSD, XPath. XML encoding is rarely used in isolation because, honestly, what's the point? Sure, your document is well-formed, but you could achieve the same thing with tab+carriage return. 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?
    - camoberg 10y ago
      YANG has a distinctly different purpose. XSD, RelaxNG, and some other alternatives were considered during the development of what eventually became YANG back in 2007. We spent quite a bit of time with XML grey beards on this topic in the IETF, and eventually realized that YANG had too many domain specific requirements that it wasn't worth trying to bend existing languages for it. 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.
      - sametmax 10y ago
        So like SOAP and XMPP ?
      - keithb- 10y ago
        Thank you for clarifying. 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.
        darfs 10y ago
        I would add the Point that XML is _the_ readable format. Just only because the seperations and nearly there is no trick-shit-thing(e.g. as in Rust, Go, C, JS, ...(that's nothing what i want to blame some language for, but seriously, nearly any language has some Tricks with it's Syntax))
        camoberg 10y ago
        Well, I would say that we did spend considerable time and energy among peoole with vast experience from designing various kinds of languages before we ended up going down the path towards what became YANG. If you poke around the IETF mailing list archives I think you will find ample amounts of justification before we were given the green light from the IAB. I meant to say "easily readable in it's native encoding". I.e. Looking at the source in your favourite text editor.
        ZenoArrow 10y ago
        Thanks for the clarification. Out of interest, did you evaluate building a Lisp DSL? If so, any pros and cons you identified from that approach? I would've thought it would have been a quicker option to get going, though if you've reached version 1 you've put in the groundwork required now.

madgar 10y ago

Your first glance may have missed that the first sentence of the RFC says it includes modeling for "Remote Procedure Calls" and "notifications for network management protocols." Your first glance may have also missed that the RFC is nearly 200 pages. Given those details, would you re-evaluate your guess?