Xiang Li <[email protected]> writes: > On 10/18/2015 8:31 AM, Ladislav Lhotka wrote: >> Xiang Li <[email protected]> writes: >> >>> On 10/16/2015 6:05 AM, Ladislav Lhotka wrote: >>>>> On 16 Oct 2015, at 12:27, Balazs Lengyel <[email protected]> >>>>> wrote: >>>>> >>>>> IMHO YANG should define the behavoir, and I would want it to be the same >>>>> on Netconf/Restconf/CLI etc. >>>>> I agree that " 1) you get an error back" would be the best: because it is >>>>> the easiest to understand for the operator, with the fewest corner cases. >>>>> Also we must define if in the same transaction we set b=42 and a=2. which >>>>> of the 3 options are taken? >>>>> >>>>> >>>>> We should not leave such complex cases undefined, or alternatively state >>>>> that they are implementation dependant. >>>> I might be difficult to say what is a complex case, unless we abandon >>>> XPath in "when" statements and use something else - and considerably >>>> simpler. >>>> >>>> Here is another interesting corner case - does it qualify as being complex? >>>> >>>> leaf-list bar { >>>> type uint8; >>>> when "count(../*) > 1"; >>>> } >>>> leaf foo { >>>> type uint8; >>>> } >>> Interesting example... >>> >>>> Assuming no instances exist, is this edit allowed? (This was essentially >>>> your question.) >>>> >>>> <bar>1</bar> >>>> <foo>2</foo> >>> I think this should succeed >>> >>>> But what about this? >>>> >>>> <bar>1</bar> >>>> <bar>2</bar> >>>> >>> I think this should succeed too because the when is satisfied in the >>> data store after the edit-config. >>> >> According to the third bullet in sec. 7.21.5 of 6020bis, a validating >> algorithm has to remove the existing "bar" instances, add a dummy >> instance and then evaluate the XPath expression. If the result is true, >> the existing "bar" instances will be put back, otherwise a validation >> error will be reported - so in our case we will have only one "bar" node, >> which is invalid. > > > Thanks you are right. I missed that... > >> >> The result of this change is that we (hopefully) made the processing of >> "when" well-defined and unambiguous, but the cost in increased comlexity >> is quite high - both for module readers and implementors of a validating >> algorithm. > yes the clarification in sec. 7.21.5 of 6020bis does make this clearer. > >> In fact, when we discussed issue Y18, my understanding was that dummy >> node manipulations will be used only if the context node is missing.
> This is something that actually still confuses me! If a context node > exists why we still need to replace it with a dummy node, especially > if an edit-config is performing a "merge" operation? This is indeed rather confusing. I think the idea was to use this procedure instead of stating that a "when" expression must not refer to any children of its context node - the procedure removes them so the result of evaluating the XPath expression is always the same no matter what's the subtree of the context node actually contains. However, the result can be that what's then in the data tree apparently violates the "when" expression. Lada > > -Xiang Li > > > >> Lada >> >>> >>> -Xiang Li >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
