Subject: subtree filtering question

From: Martin Bjorklund <[email-masked]>
Date: Sun, 07 May 2006 00:09:37 +0200 (CEST)

Hi,

While reading the subtree filtering specs again, I found something
which is a bit unclear.

Consider this example from the draft.

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users>
           <user>
             <name>fred</name>
           </user>
         </users>
       </top>
     </filter>

The question is what is the result if no user 'fred' exists?

Is it (1):

     <data>
     </data>

or (2):

     <data>
       <top xmlns="http://example.com/schema/1.2/config">
         <users>
         </users>
       </top>
     </data>   

or maybe (3):

     <data>
       <top xmlns="http://example.com/schema/1.2/config">
         <users>
           <user>
           </user>
         </users>
       </top>
     </data>   

Section 6.2.3 on containment node says:

   For each containment node specified in a subtree filter, all data
   model instances which exactly match the specified namespaces,
   element hierarchy, and any attribute match expressions are included
   in the filter output.

which seems to imply that alternative 3 is the right choice.  But in
section 6.3. it says:

   If the entire subtree data-fragment filter (starting from the root
   to the innermost element specified in the filter) exactly matches a
   corresponding portion of the supported data model, then that node
   and all its children are included in the result data.

Which seems to indicate that alternative 1 is right.  This might also
be implied by the text on content match nodes:

   o  If any containment nodes are present in the sibling set then they
      are processed further, and included if any nested filter criteria
      are also met.

(although this only seems to apply to containment nodes which are
siblings to content match nodes)

/martin

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 May 2006 22:18:44 +0200 (CEST)

Hi again.

Actually, I think that - from reading the specs - the answer is
alternative 3.

If this is the correct answer, the follow-up question is how subtree
filtering is supposed to be used to match a notification.  With XPath,
it is defined that an expression which results in an empty node set is
interpreted as 'false', and a non-empty node set is interpreted as
'true'.  If the same rule is applies to subtree filtering, a filter
such as that shown below (which produces a non-empty node set even for
a "no match") would be interpreted as true.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 May 2006 14:08:59 -0700

> a "no match") would be interpreted as true.

You are correct.
I sure do not like it, but you are correct.
The same conceptual netconf filter in xpath and subtree form
will not return the same output. That is awful.

I remember this issue came up, and the notion of removing the
entire 'dead-end' subtree from the result (back to the root)
was discussed.  That was the original intent.

The current text seems to indicate that (2) should be returned
if the <users> container is totally empty, and (3) if
it is not empty, but the requested entry 'fred' does not exist.

In either case, this is not very useful as-is for
notification filtering. Not so great for <get> filtering either.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 11 May 2006 23:19:27 +0200 (CEST)

> notification filtering. Not so great for <get> filtering either.

Well, the good thing about it is (as I think was the intent) that it's
simple to implement (for get-filtering), since the code always can
make a local decision.  And altough I haven't actually implemented a
manager, I don't think the result is difficult to interpret.

For notification filtering it's worse than not very useful, unless
someone can come up with a scheme to interpret the outcome of the
subtree filter so that it means what it's supposed to mean...

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 16 May 2006 17:12:50 +0200

Hello,
To me it seems that an important sentence is missing from the notifications draft about 
filters. The draft says:
"The format of this parameter is the same as that of the filter parameter in the NETCONF 
protocol operations."

But it does not say that filters will be applied against the data content of the 
notification or maybe just part of the notification.

One could just as well imagine filtering against the source of the notifications e.g. I am 
interested only in fault-notifications coming from one of the ethernet interface cards so 
I apply a filter against the running datastore's data
XPATH: /top/interfaces/ethernet-interfaces

Please clarify! Also we need some kind of statement exactly which part of the notification 
wil be checked.

regards Balazs