Juergen Schoenwaelder <[email protected]> writes: > On Tue, Jun 30, 2015 at 04:07:10PM +0200, Ladislav Lhotka wrote: >> >> > On 30 Jun 2015, at 15:39, Juergen Schoenwaelder >> > <[email protected]> wrote: >> > >> > On Tue, Jun 30, 2015 at 03:32:13PM +0200, Ladislav Lhotka wrote: >> >> >> >>> On 30 Jun 2015, at 15:20, Juergen Schoenwaelder >> >>> <[email protected]> wrote: >> >>> >> >>> On Tue, Jun 30, 2015 at 02:56:30PM +0200, Ladislav Lhotka wrote: >> >>>> Juergen Schoenwaelder <[email protected]> writes: >> >>>> >> >>>>> On Mon, Jun 29, 2015 at 11:49:11AM +0200, Ladislav Lhotka wrote: >> >>>>>> Hi Juergen, >> >>>>>> >> >>>>>> thank you for the review. >> >>>>>> >> >>>>>> Juergen Schoenwaelder <[email protected]> writes: >> >>>>>> >> >>>>>>> On Mon, Jun 15, 2015 at 10:49:28PM +0000, Kent Watsen wrote: >> >>>>>>>> >> >>>>>>>> This is a notice to start a NETMOD WG last call for the document >> >>>>>>>> "JSON Encoding of Data Modeled with YANG": >> >>>>>>>> >> >>>>>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-04 >> >>>>>>>> >> >>>>>>>> Please indicate your support by Monday June 29, 2015 at 9PM EST. >> >>>>>>> >> >>>>>>> Hi, >> >>>>>>> >> >>>>>>> I have reviewed draft-ietf-netmod-yang-json-04. >> >>>>>>> >> >>>>>>> - I am not sure I agree with the wording in section 3. Why is section >> >>>>>>> 8.3.3 only applicable to XML encoded data? Validation applies to >> >>>>>>> datastores. While constraints are defined using XML-based notations >> >>>>>> >> >>>>>> You are right that this section shouldn't talk about XML-encoded data, >> >>>>>> i.e. serialized form. On the other hand, XPath 1.0 spec says: "XPath >> >>>>>> operates on the abstract, logical structure of an XML document, …". >> >>>>>> >> >>>>>> So I think a datastore needs to be represented, at least conceptually, >> >>>>>> as XML infoset. >> >>>>>> >> >>>>>>> such as XPATH, how the validation is carried out is not defined in >> >>>>>>> the YANG specifications. I guess I actually disagree with the >> >>>>>> >> >>>>>> I don't think this is true. YANG spec doesn't say how "must" and >> >>>>>> "when" >> >>>>>> statements are evaluated, and relies on XPath. >> >>>>> >> >>>>> RFC 6020: >> >>>>> >> >>>>> When a datastore is validated, all "must" constraints are >> >>>>> conceptually evaluated once for each data node in the data tree, and >> >>>>> for all leafs with default values in use (see Section 7.6.1). If a >> >>>>> data node does not exist in the data tree, and it does not have a >> >>>>> default value, its "must" statements are not evaluated. >> >>>>> >> >>>>> [...]
The text you substituted here with an ellipsis is actually quite important for this discussion because it defines the context for XPath evaluation (together with section 6.4), in particular the data tree on which every XPath expression is evaluated. It is clear that the data tree can also comprise state data, notification content or RPC input/output, i.e. not only datastore content as you keep saying. Terms like "context node" refer to the XPath data model as described in sec. 5 of the XPath spec: http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model (and section 6.4 in RFC 6020 says it explicitly). We need to know, at least conceptually, how to construct the XPath data tree from JSON text. For example, it has to be clear that leaf-list entries encoded as a JSON array appear as sibling nodes in the data tree, otherwise a "must" constraint specified for the leaf-list won't work correctly. I don't think this is anyhow evident and IMO it has to be addressed. This is the purpose of section 3 in draft-ietf-netmod-yang-json-04. Would it help if "validation" is replaced with "XPath evaluation" throughout this section? Lada >> >>>>> >> >>>>> Also note that the XPath expression is conceptually evaluated. This >> >>>>> means that an implementation does not have to use an XPath evaluator >> >>>>> on the device. How the evaluation is done in practice is an >> >>>>> implementation decision. >> >>>> >> >>>> Yes, but the result must be guaranteed to be the same as if an XPath 1.0 >> >>>> processor is used, otherwise it makes really no sense. >> >>>> >> >>>>> >> >>>>>>> wording in section 3 of the JSON encoding I-D. >> >>>>>> >> >>>>>> What specifically? Do you have any suggestions for changes? >> >>>>> >> >>>>> The problem is that RFC 6020 talks about datastore validation, not >> >>>>> about validation of a specific serialization. Hence, it does not >> >>>>> matter whether the data was XML or JSON (or CBOR or whatnext) encoded >> >>>>> - once the data is in the datastore, datastore validation takes >> >>>>> place. One way to implement this is to serialize everything to XML and >> >>>>> then to use XML gear to do the validation. But this implementation >> >>>>> strategy is not required. >> >>>> >> >>>> We have no explicit concept of a metamodel for datastores but IMO the >> >>>> fact that we evaluate XPath expressions on top of it implies that the >> >>>> datastore must be (congruent to) restricted XML infoset. Section 5 (Data >> >>>> Model) is a crucial part of XPath spec, and it is XML. >> >>> >> >>> The YANG language does not require that XPath is used. It says that >> >> >> >> YANG *does* use XPath 1.0. Whether it is evaluated conceptually or >> >> otherwise is irrelevant, the results must always be the same. And >> >> evaluation of XPath requires a specific context and data model as defined >> >> in its spec. >> >> >> > >> > The YANG language definition is rather clear that (i) datastore >> > content is validated and (ii) that XPath expressions are conceptually >> > evaluated. I think the JSON encoding should not say anything >> > different. >> >> >> RFC 6020(bis) says in sec. 6.4: >> >> The data model used in the XPath expressions is the same as that used in >> XPath 1.0 [ >> XPATH], … >> >> JSON's data model is different. >> >> Therefore, I believe the yang-json document has to specify how >> (YANG-specific) JSON data map on the XPath 1.0 data model. The way how it is >> currently done is that JSON-encoded instances are (conceptually) mapped to >> XML-encoded instances, and it is assumed that the mapping of the latter to >> the XPath data model and XPath context is fully defined in YANG spec. >> >> Maybe there is a better way how to achieve the same but I am not aware of >> it, and the current way is IMO better than hand-waving. >> > > The data once decoded goes into a datastore. It is the datastore that > is validated. I quote the relevant text again: > > When a datastore is validated, all "must" constraints are > conceptually evaluated once for each data node in the data tree, and > for all leafs with default values in use (see Section 7.6.1). > > [...] > > Also note that the XPath expression is conceptually evaluated. This > means that an implementation does not have to use an XPath evaluator > on the device. How the evaluation is done in practice is an > implementation decision. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
