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-1117 yangtools <p>TypeStatement currently takes String argument, which is not entirely accurate, as it does not provide type expansion required for lookup.</p> <p>This leads to SourceExceptions during building of effective statement rather than a failure to parse the argument when the statement is being defined.</p> <p>Fix the definition of TypeStatement and TypeEffectiveStatement so that these take a QName argument.</p> <p>This leads to the question of which QNameModule should built-in types resolve – and that should be "urn:ietf:params:xml:ns:yang:1", as defined in org.opendaylight.yangtools.yang.model.util.BaseTypes. During unprefixed parsing, hence AbstractTypeStatementSupport needs to account for this manually.</p> YANGTOOLS-1117

Redefine TypeStatement in terms of QName

Improvement High Resolved Done Robert Varga Robert Varga Thu, 2 Jul 2020 17:09:58 +0000 Fri, 26 Feb 2021 07:02:27 +0000 Fri, 26 Feb 2021 07:02:27 +0000 7.0.0 parser 0 1 <p>This won't work due to polymorphic nature of TypeDefinitions. These two blocks result in different QNames:</p> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> leaf foo {   type string; }   leaf bar { type string {     pattern <span class="code-quote">"a.c"</span>;   } }</pre> </div></div> <p>In the first case it resolves to a built-in type, hence it will be have the YANG namespace. In the second case it resolves to a restricted type and it will have the module's namespace.</p> <p>We can consider using AbstractQName and its QualifiedQName/UnqualifiedQName – but it does not seem to be worth the hassle.</p> <p> </p> <p> </p> <p>Actually this conflating two separate issues:</p> <ul> <li>'type' statement's QName</li> <li>its TypeDefinition QName</li> </ul> <p>We need to keep them separate, as the attempts to fuse them via TypeDefinition.copy() effort elsewhere. This issue just needs the QName definition as per description.</p> Issue split YANGTOOLS-1262 Development Rank 0|i03tfr: