[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sub-tree filtering proposals
On Fri, May 28, 2004 at 02:56:05PM -0700, Andy Bierman wrote:
>
> A) Issue 14.1: Subset specification
>
> A.1) Extensibility
>
> The <get> and <get-config> operations should be modified to
> allow for the utilization of different types of standard,
> proprietary, and experimental filter mechanisms in an extensible
> way.
> - An additional containment layer (called <filter>) is needed
> above the user data model content in the get operation <rpc>
> message.
> - The <filter> element can appear zero or one times
> - There is one attribute defined, called 'filter-type', which
> identifies the type of filter processing requested by the manager
> - The content type is 'any' (any element outside the netconf
> namespace)
Any specific reason why you want to put the <filter/> element into
the <data/> element? Why not just do the following:
<rpc message-id="101" xmlns="netconf-uri">
<get>
<filter filter-type="subtree">
<foo xmlns="http://example.com/schema-1"/>
</filter>
</get>
</rpc>
<rpc-reply message-id="101" xmlns="netconf-uri">
<data>
<foo xmlns="http://example.com/schema-1";>7</foo>
</data>
</rpc-reply>
> B) Issue 14.1.2: Subtree Filtering
> ----------------------------------
[...]
Out of curiosity, I am wondering how this subtree matching relates to
XPATH filters or a subset thereof. So I started a little exercise to
write XPATH expressions for your examples. In fact, it might be useful
if the subtree filtering actually can be translated into XPATH
expressions automatically on boxes that are capable to do XPATH
filtering (so you just have one piece of filtering logic).
Some open issues are listed at the end. Perhaps someone with more XPATH
experience can answer some of them.
> C) Examples
> -----------
>
> C.1: No filter
>
> Request:
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> </data>
> </get>
> </rpc>
>
> Reply:
>
> <rpc-reply message-id="101" xmlns="netconf-uri">
> <data>
> ... entire set of data models returned ...
> </data>
> </rpc-reply>
>
> Notes:
>
> - Since the sub-tree filter is inclusive, and the start state
> is the empty set, the best way to get everything on the
> agent is to leave out the filter. Not sure the best way
> to fit this into <get> and <get-config> operations though.
The equivalent XPATH expression might be "//*".
> C.2: Empty filter
>
> Request:
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> <filter type="subtree">
> </filter>
> </data>
> </get>
> </rpc>
>
> Reply:
>
> <rpc-reply message-id="101" xmlns="netconf-uri">
> <data>
> </data>
> </rpc-reply>
>
> Notes:
>
> - Nothing is selected because no content match or selection
> nodes are present. This is not an error.
I think there are several XPATH expressions that produce an empty result
- not sure yet which is the nicest (not that this is really important).
> C.3) Select the entire <users> sub-tree
>
> Request:
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> <filter filter-type="subtree">
> <users xmlns="http://example.com/schema-1"/>
> </filter>
> </data>
> </get>
> </rpc>
>
> Reply:
>
> <rpc-reply message-id="101" xmlns="netconf-uri">
> <data>
> <users xmlns="http://example.com/schema-1";>
> <user>
> <name>root</name>
> <type>superuser</type>
> <full-name>Charlie Root</full-name>
> <company-info>
> <dept>1</dept>
> <id>1</id>
> </company-info>
> </user>
> <user>
> <name>fred</name>
> <type>admin</type>
> <full-name>Fred Flintstone</full-name>
> <company-info>
> <dept>2</dept>
> <id>2</id>
> </company-info>
> </user>
> <user>
> <name>barney</name>
> <type>admin</type>
> <full-name>Barney Rubble</full-name>
> <company-info>
> <dept>2</dept>
> <id>3</id>
> </company-info>
> </user>
> </users>
> </data>
> </rpc-reply>
>
> Notes:
>
> - The filter contains one selection node (<users>), so just
> that sub-tree is selected by the filter
> - This example represents the fully-populated <users> data model
> in most of the filter examples that follow. In a real
> data model, the 'company-info' would not likely be returned
> with the list of users for a particular host or network.
The equivalent XPATH expression might be "//users" or "/users"
(not sure yet what precisely your semantics are here).
> - The following filter request would have produced the same
> result, but only because the container <users> defines one
> child element (<user>)
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> <filter filter-type="subtree">
> <users xmlns="http://example.com/schema-1";>
> <user/>
> </users>
> </filter>
> </data>
> </get>
> </rpc>
The equivalent XPATH expression might be "//users/user" or "/users/user"
(not sure yet what precisely your semantics are here).
> C.4) Select all 'name' elements within the 'users' sub-tree
>
> Request:
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> <filter filter-type="subtree">
> <users xmlns="http://example.com/schema-1";>
> <user>
> <name/>
> </user>
> </users>
> </filter>
> </data>
> </get>
> </rpc>
>
> Reply:
>
> <rpc-reply message-id="101" xmlns="netconf-uri">
> <data>
> <users xmlns="http://example.com/schema-1";>
> <user>
> <name>root</name>
> </user>
> <user>
> <name>fred</name>
> </user>
> <user>
> <name>barney</name>
> </user>
> </users>
> </data>
> </rpc-reply>
>
> Notes:
>
> - This filter contains two containment nodes (users, user),
> and one selector node (name).
> - All instances of the 'name' element in the same sibling set
> are selected in the filter output.
> - The manager may need to know that 'name' is used as an
> instance identifier in this particular data structure,
> but the agent does not need to know that meta-data in
> order to process the request.
The equivalent XPATH expression might be "//users/user/name".
> C.5) One specific <user> entry
>
> Request:
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> <filter filter-type="subtree">
> <users xmlns="http://example.com/schema-1";>
> <user>
> <name>fred</name>
> </user>
> </users>
> </filter>
> </data>
> </get>
> </rpc>
>
> Reply:
>
> <rpc-reply message-id="101" xmlns="netconf-uri">
> <data>
> <users xmlns="http://example.com/schema-1";>
> <user>
> <name>fred</name>
> <type>admin</type>
> <full-name>Fred Flintstone</full-name>
> <company-info>
> <dept>2</dept>
> <id>2</id>
> </company-info>
> </user>
> </users>
> </data>
> </rpc-reply>
>
> Notes:
>
> - This filter contains two containment nodes (users, user)
> and one content match node (name).
> - All instances of the sibling set containing 'name',
> for which the value of 'name' equals "fred", are selected
> in the filter output.
The equivalent XPATH expression might be "//users/user[name="fred"]".
> C.6) Specific elements from a specific <user> entry
>
> Request:
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> <filter filter-type="subtree">
> <users xmlns="http://example.com/schema-1";>
> <user>
> <name>fred</name>
> <type/>
> <full-name/>
> </user>
> </users>
> </filter>
> </data>
> </get>
> </rpc>
>
> Reply:
>
> <rpc-reply message-id="101" xmlns="netconf-uri">
> <data>
> <users xmlns="http://example.com/schema-1";>
> <user>
> <name>fred</name>
> <type>admin</type>
> <full-name>Fred Flintstone</full-name>
> </user>
> </users>
> </data>
> </rpc-reply>
>
> Notes:
>
> - This filter contains two containment nodes (users, user),
> one content match node (name), and two selector nodes
> (type, full-name).
> - All instances of the 'type' and 'full-name' elements in
> the same siibling set containing 'name', for which the value
> of 'name' equals "fred", are selected in the filter output.
> The 'company-info' element is not included because the
> sibling set contains selection nodes.
The XPATH expression "//users/user[name="fred"]/name" will just return
the name element - not sure how one can select multiple elements with
XPATH in this case (but I am an XPATH beginner - perhaps someone out
there knows the answer).
> C.7) Multiple sub-trees
>
> Request:
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> <filter filter-type="subtree">
> <users xmlns="http://example.com/schema-1"/>
> <user>
> <name>root</name>
> <company-info/>
> </user>
> <user>
> <name>fred</name>
> <company-info>
> <id/>
> </company-info>
> </user>
> <user>
> <name>barney</name>
> <type>superuser</type>
> <company-info>
> <dept/>
> </company-info>
> </user>
> </users>
> </filter>
> </data>
> </get>
> </rpc>
>
> Reply:
>
> <rpc-reply message-id="101" xmlns="netconf-uri">
> <data>
> <users xmlns="http://example.com/schema-1"/>
> <user>
> <name>root</name>
> <company-info>
> <dept>1</dept>
> <id>1</id>
> </company-info>
> </user>
> <user>
> <name>fred</name>
> <company-info>
> <id>2</id>
> </company-info>
> </user>
> </users>
> </data>
> </rpc-reply>
>
> Notes:
>
> - This filter contains three sub-trees (name=root, fred, barney)
> - The "root" sub-tree filter contains two containment nodes (users,
> user), one content match node (name), and one selector node
> (company-info). The sub-tree selection criteria is met, and just
> the company-info sub-tree for "root" is selected in the filter
> output.
//users/user[name="root"]/company-info
> - The "fred" sub-tree filter contains three containment nodes
> (users, user, company-info), one content match node (name), and
> one selector node (id). The sub-tree selection criteria is met,
> and just the 'id' element within the company-info sub-tree for
> "fred" is selected in the filter output.
//users/user[name="fred"]/company-info/id
> - The "barney" sub-tree filter contains three containment nodes (users,
> user, company-info), two content match nodes (name, type), and one
> selector node (dept). The sub-tree selection criteria is not met
> because user "barney" is not a "superuser", and the entire sub-tree
> for "barney" (including its parent 'user' entry) is excluded from
> the filter output.
//users/user[name="barney" and type="superuser"]/company-info
You can combine these these expressions using a pipe character:
//users/user[name="root"]/company-info |
//users/user[name="fred"]/company-info/id |
//users/user[name="barney" and type="superuser"]/company-info
> C.8) Table with attribute naming
>
> Request:
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> <filter filter-type="subtree">
> <t:interfaces xmlns:t="http://example.com/schema-2"/>
> <t:interface t:ifName="eth0"/>
> </t:interfaces>
> </filter>
> </data>
> </get>
> </rpc>
>
> Reply:
>
> <rpc-reply message-id="101" xmlns="netconf-uri">
> <data>
> <t:interfaces xmlns:t="http://example.com/schema-2";>
> <t:interface t:ifName="eth0">
> <t:ifInOctets>45621</t:ifInOctets>
> <t:ifOutOctets>774344</t:ifOutOctets>
> </t:interface>
> </t:interfaces>
> </data>
> </rpc-reply>
>
> Notes:
>
> - This filter contains one containment node (interfaces), one
> attribute match expression (ifName), and one selector node
> (interface).
> - All instances of the 'interface' sub-tree which have an
> ifName attribute equal to "eth0" are selected in the
> filter output.
> - The filter data elements and attributes must be qualified
> because the 'ifName' attribute will not be considered part
> of the 'schema-2' namespace if it is unqualified.
> - If 'ifName' were a child node instead of an attribute, then
> the following request would produce the same results:
>
> <rpc message-id="101" xmlns="netconf-uri">
> <get>
> <data>
> <filter filter-type="subtree">
> <interfaces xmlns="http://example.com/schema-2";>
> <interface>
> <ifName>eth0</ifName>
> </interface>
> </interfaces>
> </filter>
> </data>
> </get>
> </rpc>
interfaces/interface/[@ifName="eth0"]
OPEN ISSUES:
- I have ignored namespaces so far. I am sure XPATH will have a way
to deal with them. Not sure though how that looks like in concrete
syntax (and how ugly it will be).
- I do not yet know how to select several elements (kind of doing a
projection on elements) (see example C.6 above).
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>