> On 01 Jul 2015, at 14:33, Juergen Schoenwaelder > <[email protected]> wrote: > > On Wed, Jul 01, 2015 at 02:03:15PM +0200, Ladislav Lhotka wrote: >> >>> On 01 Jul 2015, at 09:21, Juergen Schoenwaelder >>> <[email protected]> wrote: >>> >>> On Wed, Jul 01, 2015 at 08:54:07AM +0200, Ladislav Lhotka wrote: >>>> 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? >>> >>> No. I continue to believe (a) a datastore is validated and not an XML >>> infoset (or something like that) and (b) that the evaluation of "must" >>> constraints is conceptual. >> >> Both NETCONF and YANG are absolutely silent about the data model of a >> datastore, so I assume it can be pretty much anything. Can you explain how a >> “must” constraint is conceptually evaluated on, say, key-value database? >> > > This is a question to answer by someone who implements it on a > key-value database.
Note that RFC 6020 just has XML mapping sections and otherwise tells nothing about how instances of data nodes are represented in a datastore. I have thus always assumed that everything works fine because the datastore model is essentially XML Infoset, except that “data tree” is used instead of “infoset”, “data node” instead of “information item” etc. In any case, with RFC 6020 in hand I can only explain how JSON is mapped to XML. I have no idea how to get JSON data into a datastore of unknown data model (which you take for granted), and then conceptually evaluate XPath expressions on it. > > I feel we are wasting time and energy here. Indeed, and it is frustrating. However, I’d like to know what to do with section 3 of the yang-json document. 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
