<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:55:40 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[YANGTOOLS-1271] Expose SchemaInferenceStack.effectiveConfig()</title>
                <link>https://jira.opendaylight.org/browse/YANGTOOLS-1271</link>
                <project id="10188" key="YANGTOOLS">yangtools</project>
                    <description>&lt;p&gt;Current parser does not accurately process config statements, relying on DocumentedNode&apos;s and explicit lookups in parent. This means that users looking through EffectiveStatement hierarchy do not always see the config substatement when they should.&lt;/p&gt;

&lt;p&gt;For example, given the following model:&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;module foo {
  prefix foo;
  namespace foo;

  grouping grp {
    container foo;
    container bar {
      config false;
    }
  }

  container baz {
    uses grp;
  }

  container oper {
    uses grp;
    config false;

    container cont;
  }

  rpc xyzzy {
    input {
      uses grp;
    }
  }
}&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Should observe the following:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;baz should have an implicit &apos;config true&apos; substatement (as it is the default)&lt;/li&gt;
	&lt;li&gt;baz/foo should have an implicit &apos;config true&apos; substatement (as it is the default/implied by parent)&lt;/li&gt;
	&lt;li&gt;oper/foo should have an implicit &apos;config false&apos; substatement (as it is implied by parent)&lt;/li&gt;
	&lt;li&gt;oper/cont should have an implicit &apos;config false&apos; substatement (as it is implied by parent)&lt;/li&gt;
	&lt;li&gt;xyzzy/input/bar should &lt;b&gt;not&lt;/b&gt; have a config substatement (as it is instantiated in a context which ignores config)&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;&#160;Note this has implications on memory efficiency and general lifecycle of uses/augment mechanics, hence we need to carefully evaluate the solution.&lt;/p&gt;</description>
                <environment></environment>
        <key id="33897">YANGTOOLS-1271</key>
            <summary>Expose SchemaInferenceStack.effectiveConfig()</summary>
                <type id="10100" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10310&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="2" iconUrl="https://jira.opendaylight.org/images/icons/priorities/critical.svg">High</priority>
                        <status id="10003" iconUrl="https://jira.opendaylight.org/images/icons/status_generic.gif" description="">Confirmed</status>
                    <statusCategory id="2" key="new" colorName="blue-gray"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="rovarga">Robert Varga</reporter>
                        <labels>
                            <label>pt</label>
                    </labels>
                <created>Tue, 13 Apr 2021 10:52:37 +0000</created>
                <updated>Thu, 18 Jan 2024 10:42:40 +0000</updated>
                                                            <fixVersion>14.0.0</fixVersion>
                    <fixVersion>11.0.6</fixVersion>
                    <fixVersion>13.0.2</fixVersion>
                                    <component>model-api</component>
                    <component>model-util</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>1</watches>
                                                                                                                <comments>
                            <comment id="70315" author="rovarga" created="Wed, 1 Dec 2021 12:48:42 +0000"  >&lt;p&gt;At least the conjuring part needs purely-effective statements.&lt;/p&gt;

&lt;p&gt;The suppression part can probably work in similar way as deviate works.&lt;/p&gt;</comment>
                            <comment id="70350" author="rovarga" created="Sun, 12 Dec 2021 19:18:51 +0000"  >&lt;p&gt;The current requirement is really driven by DataSchemaNode.effectiveConfig(), i.e. the statement itself needs to know its effective configuration. This is important in SchemaNode world, as all its users usually work on a single SchemaNode, with the odd exception here and there where also the parent DataNodeContainer is considered.&lt;/p&gt;

&lt;p&gt;In EffectiveStatement world, though, having this knowledge directly in the statement is not as critical. Users here typically work with EffectiveStatementInference, which conceptually captures the path from&#160; root. We also have SchemaInferenceStack as the baseline utility for all sorts of inferences on the statement tree.&lt;/p&gt;

&lt;p&gt;Hence if we take SchemaNodes out of the picture, we could expose this information from SchemaInferenceStack, i.e. host DataSchemaNode.effectiveConfig() there and calculate the result based on stack. With such a design we can almost ditch the flags field from effective statements, allowing for a much more aggresive statement reuse in the parser.&lt;/p&gt;

&lt;p&gt;Unfortunately this is somewhat counter-intuitive from object model perspective, as config/status end up not being strictly effective &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.opendaylight.org/images/icons/emoticons/sad.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="71942" author="rovarga" created="Wed, 25 Jan 2023 03:16:27 +0000"  >&lt;p&gt;The last sentence is okay. What we need to ensure is that we document EffectiveConfigStatement mechanics explicitly &#8211; both in its description and call it out in the general model.api.stmt contract description.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10003">
                    <name>Relates</name>
                                                                <inwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="33898">YANGTOOLS-1272</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10002" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>YANGTOOLS-1269</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i03xp3:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>