> 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.

Lada  

> 
> /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

Reply via email to