[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NETCONF Instance Identifiers

Phil Shafer wrote:

Andy Bierman writes:

1) There is a 'fixed' root, starting at <rpc>, for methods
   and data.  There is also a conceptual 'relative' root for data.
   This is unnamed, and will be called <config> or <data> or <filter>
   in a NETCONF PDU.  There is no default namespace associated with
   the root.


<rpc> or <config>?


/rpc for RPC methods and <error-path>

relative root <config> == <data> == <filter>, etc.) for data




   /foo/bar[x="3",y="4"]


Stick w/ xpath syntax and use "and":


OK



   /foo/bar[x=3 and y=4]


3) Unnamed instances (e.g. maxOccurs="unbounded") are identified
   by their position (relative to other instances of the same element),
   using a special INDEX component called 'position'.  Unnamed
   instances are numbered starting at zero.  Conceptually, all
   unnamed, single-instance elements can be identified as position="0".

   E.g.: <goo> is a simple type that can occur 0 or more times

   /foo/bar[x="3",y="4"]/baz[name="fred"]/zoo/goo[position="3"]


This makes "position" a magic token.  In XPath, position() is a
function that does approximately the same thing (origin 1).

    goo[position() = 3]


OK




4) RPC methods are identified by their path from the absolute root,
   and instance identifiers used within <error-path> elements may identify
   the entire path to the <rpc> element.

   /rpc/edit-config/error-option

   /rpc/edit-config/config/interfaces/interface[name="eth0"]


I don't follow you here.  Why would an xpath originated at
/rpc/ be valuable?


It is needed to identify the bad parameter, which could
be <error-option> just as well as something in the data
underneath <config>




5) If namespaces are used then components within the Xpath expression
   must consist of properly formatted Qualified Names.
  /nc:rpc/edit-config/config/acme:interfaces/interface[name="eth0"]


Yup, and don't forget the joys of namespaces and attributes.

But I feel like I'm missing something.  Aren't we really needing
something in the schema that defines what elemenents are identifiers,
rather than XPath syntax for it?  My developer/app needs to know
that the "interface" element is identified by the "name" element
and the most convenient place to "know" this is the schema that
defines the "interface" element.



Yes we do need that to tell the tools about the data structure.
We do not need that to identify data instances within <error-path>
elements.  Using a common format for a conceptual instance identifier
is useful beyond this 1 element of course, but currently out of scope.
But if we decide to create a standard 'config-change' notification,
then it will be useful to identify what changed without returning
all the changed XML.



Thanks,
 Phil


Andy



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>