[YANGTOOLS-591] Report error if default value for typedef fails constraint validation from typedef or base typedef Created: 14/Mar/16 Updated: 10/Apr/22 Resolved: 16/Oct/16 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | David M. Karr | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||
| Description |
|
Yangtools should be augmented to report an error in the following block: typedef listen-ipv4-address { type iit:ipv4-address; //default "0.0.0.0"; default "xxx"; }The value of "xxx" provided for "default" does not match the constraints of the base type (ipv4-address), which is defined by a pattern. In the Xored YangIDE Eclipse plugin, which uses Yangtools, this does not report an error. In constrast, the Pyang Python compiler reports the following: error: the value "xxx" does not match its base type at ietf-inet-types.yang:179 - pattern mismatch for the default value for pattern defined at ietf-inet-types.yang:184 This is as used in the Yang Design Studio Eclipse plugin, which utilizes Pyang. When I reported this in the yangtools-dev mailing list, Robert Varga indicated "it would require I'm interested in any issues that show a disparity between what pyang acknowledges as valid Yang code, compared to Yangtools. This isn't to be "competitive", it's simply to provide consistency with other tools in the domain. |
| Comments |
| Comment by David M. Karr [ 14/Mar/16 ] |
|
Note that I understand there is debatable ambiguity in the Yang specification, specifically in this area (and I'm sure in others), but I think it's reasonable to look past that and consider what's "reasonable and logical", and experience from existing implementations. Specifically, irrespective of whether the Yang specification is clear on whether or how the default value could ever be used, I can't see how anyone could argue that there's any doubt that it's reasonable for the value specified as the "default" to not be valid according to the constraints of the type or its base types. It's also reasonable to consider that at least one Yang compiler, being Pyang, explicitly states that this value needs to be validated against those constraints. Being consistent with other existing implementations, even if by ad hoc conventions, is good for all users of both products. |
| Comment by Tony Tkacik [ 25/Apr/16 ] |
|
Probably duplicate of 4650 |