Do not use SchemaNode in yang-data
(YANGTOOLS-1244)
|
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | data-impl |
| Affects Version/s: | None |
| Fix Version/s: | 10.0.0 |
| Type: | Sub-task | Priority: | High |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | pt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Schema-aware builders are a major point of proliferation of SchemaNode usage. They were the first cut at getting some validation going, but have been found to be lacking. One key area is that their API does not lend any help towards guiding actual SchemaNode transition, which is actually the more painful task when compared to the task of validating structure. The second area is the lifecycle, where Builder API would like us to believe the world is quite linear. This is not really true in anything but example code, as we typically need to deal with event-driven parsing, potentially reentrant builders (i.e. XML list encoding). This again requires another layer for tracking related state – where we keep builders organized by parsing state. The third area is completeness of validation. SchemaAware builders do not really establish what is their validation scope, hence anybody hoping for a reasonably complete validation will find them lacking:
On the other hand we have at least two other frameworks which can perform a number of such validation tasks, hence long-term it is a better idea to generalize existing working solutions rather than trying to fit them into the constrained framework of schema-aware builders. Remove schema-aware builder implementations, opting for simplicity of schemaless builders instead. |