Subject: [netmod] Fwd: Re: Order of evaluation for when?

From: Xiang Li <[email-masked]>
Date: Fri, 16 Oct 2015 18:13:37 -0500

On 10/16/2015 6:05 AM, Ladislav Lhotka wrote:
>> On 16 Oct 2015, at 12:27, Balazs Lengyel <[email-masked]> 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.

-Xiang Li

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 18 Oct 2015 15:31:31 +0200

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

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.

In fact, when we discussed issue Y18, my understanding was that dummy
node manipulations will be used only if the context node is missing.

Lada

>
>
> -Xiang Li
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Xiang Li <[email-masked]>
Date: Sun, 18 Oct 2015 13:21:12 -0500

> error will be reported - so in our case we will have only one "bar" node,

Thanks  you are right. I missed that...

> is quite high - both for module readers and implementors of a validating
yes the clarification in  sec. 7.21.5 of 6020bis   does make this clearer.

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

-Xiang Li

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Oct 2015 10:39:20 +0200

> 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