-
Epic
-
Resolution: Unresolved
-
Highest
-
None
-
None
-
None
-
None
-
Operating System: All
Platform: All
-
Anydata Support
In order to adequately support RESTCONF, we need to be able to express and parse anydata nodes.
Otherwise RESTCONF, eventhough it deals with YANG-modeled data, ends up needing to deal with parsing and making subcalls to our parsers.
To address this we need solve a couple of issues:
1) Define AnyDataNode semantics and what sort of interface they provide.
DOMSource for AnyXmlNode is not the right model, as it prevents lazy instantiation and binds us to a particular representation model. This was a mistake, as the provider/consumer interface should allow extension and interpretation.
The provider knows how the data is structured and the consumer knows what data it can consume. Notably, a RESTCONF northbound can fully resolve anydata based on siblings of the anydata leaf – hence the result would be a plain NormalizedNode of the appropriate type.
In cases when we cannot reliably determine the data schema, we can provide at least some data representation, which can then be resolved.
2) Define AnyDataNode parsing mechanics and provide adequate plugin interfaces.
Specifically this means that for an anydata node, the parser needs to perform a call out to its user, who needs to decode the node. For specific case of RESTCONF, it needs the contents of the node's siblings to determine how to decode the data – so if they are already known, it can reuse the JsonReader instance. If they are not known, it needs to be called once they are known.
- blocks
-
NETCONF-425 Update yang-patch support to RFC8072
- Confirmed
- is blocked by
-
YANGTOOLS-778 Add support for restconf:yang-data extension
- Resolved
- is duplicated by
-
YANGTOOLS-785 Add support of Yang 1.1 statements in JSON/XML stream writer/parser
- Resolved
- relates to
-
YANGTOOLS-764 yang-data-api: define the concept of a tainted NormalizedNode
- Confirmed