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.
> >>>>> 
> >>>>> [...]
> >>>>> 
> >>>>> 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/>

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to