https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-1114 yangtools <p>Our current definition of DefaultEffectiveStatement (and declared statement by extension) requires users to manually parse the value to correlate it to the actual value.</p> <p>What we really would like to say is that both these have a bound value, which is bound the parent type – i.e. the bracket is EffectiveStatement&lt;Object&gt;, specialized to Uint16 for uint16 types.</p> <p>Since we are required to parse the argument when a statement is defined, this needs some more thought as to the inference mechanics – i.e. before we can successfully create the statement we need to have its parent statement perform type inference to resolve the base type.</p> YANGTOOLS-1114

Reconsider DefaultEffectiveStatement definition

Improvement High Confirmed Unresolved Unassigned Robert Varga Tue, 23 Jun 2020 16:11:49 +0000 Fri, 5 Jan 2024 14:59:38 +0000 14.0.0 parser 0 1 <p>DataNodeIdentifier is our candidate for yang.common's representation of YANG's instance-identifier type.</p> <p>RFC7950 defines four places where a 'default' statement can occur, which boil down to two distinct kinds:</p> <ol> <li>when used under a 'typedef', a 'leaf' or a 'leaf-list', where it binds to the value domain (i.e. boils down to one of the built-in types, perhaps restricted)</li> <li>when used under a 'choice', where it binds to a child case identifier, i.e. it boils down to QName along the SchemaNodeIdentifier axis</li> </ol> <p>The value domain part a bit thorny where 'instance-identifier', 'leafref' and 'identityref' type are concerned, as they differ in how namespaces are bound. In both cases qualified qnames are bound at the declaration site, but then unqualified qnames are</p> <ol> <li>bound at the declaration site for 'typedef' default</li> <li>bound at the particular instantiation site for 'leaf' and 'leaf-list' default</li> </ol> <p>We need to consider all of these in this design. I think we can expend some memory in making an indirection, i.e. to have a DefaultArg interface and that providing access to values. I think it is fair for parser implementation to provide QualifedBound values for leaf/leaf-list, just as is the case with XPath expressions. Users usually have the means to understand the default namespace at the instantiation site.</p> <p>The other part is that we need to understand how the type system is wired before we call DefaultStatementSupport.parseArgument(), simply because we want immutable classes and in order to correctly interpret the incoming string we need to know in what domain it resides.</p> <p>This implies that all statements which could potentially be holding back a default statement <b>must</b> be present in a previous phase &#8211; and must gate its finalization of that previous phase with inference actions, so that when that previous phase completes, 'default's parent has either a populated namespace, or can reconstruct that information on demand (for example via a vritual namespace?).</p> Relates YANGTOOLS-1356 Development Rank 0|i03t7z: