Subject: [netmod] XPath document root

From: Andy Bierman <[email-masked]>
Date: Sat, 27 Dec 2008 07:20:04 -0800

Hi,

The meaning of the docroot '/' within an AbsoluteLocationPath [rule 1]
is not specified in the YANG draft.  It changes depending on
the context node.

Not sure how to specify this, but here is a first draft...

For a node within a NETCONF database, the document root is
associated with the <config> node,. E.g., a reference
such as /if:interfaces/if:interface is aligned with
<get> or <get-config> operations, such that <if:interfaces>
is a child node of <config>.

For a node within an RPC method, the document root is
associated with the parent of the <rpc> element.
E.g., a reference such as /nc:rpc/nc:get-config/nc:filter
contains all the elements in the PDU. (Note the conceptual
'input' node is not present in the XPath for must/when/instance-id,
but it is present for keyref.)

For a node within a notification, the document root is
associated with the parent of the <notification> element.
E.g., a reference such as /ncn:notification/not:replayComplete
contains all the elements in the PDU.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Dec 2008 11:11:28 +0100 (CET)

> is a child node of <config>.

I agree with this principle.

> contains all the elements in the PDU.

These XPath expressions are used in 'must', 'when' and 'path'
(keyref/leafref).  For example:

   rpc foo {
     input {
       leaf a { ... }
       leaf b {
          must "../a > .";
          ...
       }
     }
   }

So for 'must' and 'when', the tree to operate on should be the
rpc/notification itself.  But I don't quite see why the root would be
the 'rpc' element; I think it should be the rpc/notification being
defined.  In the example above it would be 'foo'.

But for 'path' expressions, this does not make much sense.  As an
example, consider this:

  notification link-down {
    leaf if-name {
      type keyref {
        path "/if:interface/if:name";
      }
    }
  }

Here, the intention is that the docroot of the path expression is the
conceptual root of the running data store.  In fact, it should be
running + operational.

This would mean that there is no way to address rpc/notification-local
instances with keyref, unless we allow them to be addressed with
relative xpath expressions:

  rpc foo {
    input {
      list a { ... }
      leaf b {
        type keyref {
           path "../a/name";
        }
      }
    }
  }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Dec 2008 07:34:02 -0800

> defined.  In the example above it would be 'foo'.

The <rpc> element is the start of the XML instance document.
What is allowed for absolute path expressions?

Is must "/nc:rpc/nc:edit-config/nc:test-option = 'set'";
permitted as a legal statement?

Or maybe must "../../test-option";

Either way (starting at root, or using the parent node ..)
you have to know which element is the document root.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Dec 2008 08:19:10 -0800

> defined.  In the example above it would be 'foo'.

Here is a better example showing 2 XPath issues (augment targets
are different than XPath paths:

   augment "/nc:rpc/nc:edit-config/nc:input" {

     when "/nc:rpc/nc:edit-config/nc:test-option = 'test-then-set'";

     leaf my-test-option { ... }

   }

Also, there is a 4th root, <rpc-reply>, when rpc output nodes are
being referenced.

Unless the entire PDU is available to the DM designer,
there is no point is having all the user XML attributes
in the <rpc> element (mirrored in <rpc-reply>)

   augment /a/b/c {
     when "/nc:rpc[@my-attr = '42']";

     leaf forty-two-addons { ... }
   }

Also, how is the expression "//foo" evaluated?
Where is the 'top' for the expression evaluation code
to start looking for 'foo' nodes?

Obviously, processing for the ancestor and ancestor-or-self axis
needs this clarification as well.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Dec 2008 21:01:46 +0100 (CET)

>      leaf my-test-option { ... }

The augment expression should be:

  augment "/nc:edit-config/nc:input" { ... }

There is no schema node 'rpc' in the NETCONF yang module (I had a look
at your version, and you have one, defined as config data...)

> in the <rpc> element (mirrored in <rpc-reply>)

I never understood why this attribute mirroring is important (we
should ask Phil again, and write it down), but I'm quite sure the
intention was not for DM designers to get access to the attributes.

> to start looking for 'foo' nodes?

For an rpc definition of 'my-op', I think the tree should be:

  <my-op xmlns="namespace-of-module">
    <input>
      ...
    </input>
    <output>
      ...
    </output>
  </my-op>

Hmm... another issue is if this is legal, and what it means:

   rpc my-op {
     input {
       leaf foo {
          when "/my-op/output/x";
       }
   }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Dec 2008 12:32:05 -0800

>   augment "/nc:edit-config/nc:input" { ... }

OK -- this is simpler and good enough

> intention was not for DM designers to get access to the attributes.

It was left up to the DM designers.
The use-case was different applications for the <rpc-reply>
than the one that generated the <rpc> request.  It is
an app-to-app messaging mechanism, passed through the agent.

We could leave /rpc and /notification out of YANG.
IMO, it is no more or less stupid than:

   when "../ifInOctets mod 2";

which is perfectly legal YANG.

But let's make the root for RPCs the method name node,
and for notifications, the notification content node.
That's fine.

> Hmm... another issue is if this is legal, and what it means:

This is legal but not going to work.

The 'foo' when-stmt is evaluated at the time the <rpc> PDU is
received.  At that time, there is no <rpc-reply> yet.
Therefore, all references to such nodes will produce
a 'false' result.

IMO, the docroot for RPC input/output should be
the <input> and <output> nodes, which will completely
remove the possibility of referencing outside the
scope of the 'current document'.

     rpc foo {
       input {
          leaf x { must '../y != 10'; type string; }
          leaf y { mandatory true; type string; }
       }
     }

That looks better and matches the intent of the feature.

XPath is designed to work against a single XML instance document.
Let's keep it that way.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Dec 2008 23:23:15 +0100 (CET)

> That looks better and matches the intent of the feature.

Yes, you're right.   I will try to specify this in -03.

/martin