Re: [netmod] definition of "fully expanded YANG"

Robert Varga <> Wed, 17 July 2019 14:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC22F120409 for <>; Wed, 17 Jul 2019 07:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XM5jEckHS5Rj for <>; Wed, 17 Jul 2019 07:32:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60B241205D7 for <>; Wed, 17 Jul 2019 07:32:25 -0700 (PDT)
Received: from nitebug.nitenet.local ( []) by (Postfix) with ESMTPSA id 3C299243F98; Wed, 17 Jul 2019 16:32:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1563373942; bh=F3rkqQNaM9kyD9Fo7Yi6cfPvzoe9NhTdznhROgt8sTw=; h=Subject:To:References:From:Date:In-Reply-To; b=WIyBd0nqnIK48KupxnYUhwyAOh2mqF8j0eMYrhXRRRGSO3f4VCtuBxi6hiN5wU3/A lklalv3cMw3dpdru0rKKNIR0tlA216kI1v28eBxpGS/JrE1FDC1T72EKWJ99qhzhfn WH6v08YfweGl1IctpWf1+8DvBfAPJ+kUTiSP09os=
To: Michael Rehder <>, "" <>
References: <> <> <> <>
From: Robert Varga <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Wed, 17 Jul 2019 16:32:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="QqenCvsxKvy7dXcXKFETMJQhYUSH3N476"
Archived-At: <>
Subject: Re: [netmod] definition of "fully expanded YANG"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jul 2019 14:32:28 -0000

On 17/07/2019 15:54, Juergen Schoenwaelder wrote:
> On Wed, Jul 17, 2019 at 01:18:57PM +0000, Michael Rehder wrote:
>> Yes, inlining of everything, including augments. What you'd see in the tree representation.
>> For example augments makes it particularly impossible for a consumer of the YANG schema to process the schema since the final result.
>> Some use cases:
>> - translating to another schema language
>> - translating to a UI dialog for data entry
>> - an accurate diff on versions
>> Model-driven-design means using the "computable specification" for all sorts of things, increasing the ROI of the schema definition.
> It sounds to me like you are interested in what compiler people call
> the abstract syntax tree, which is quite a different thing than the
> YANG module you start with. The easiest and most robust way to do
> translations is likely to simply expand pyang (or any other compiler
> of choice).

Depends on how you define the AST (and how many different ASTs are in
your compiler), as .yang file has an AST itself, which you then
cross-reference between modules/submodules, and you arrive at some IR,
from which you derive the effective model with whatever indices/details
your use case requires.

This is certainly possible with OpenDaylight tooling, i.e. arrive at,
which gives you a per-module tree of statements with all RFC7950
semantic processing applied. It also contains some generally-useful
indices (like schema tree/data tree traversal) as well as references to
original statement declaration (i.e. as it appeared in .yang file, if