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

Re: subtree filtering question

Martin Bjorklund wrote:

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.



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






Martin Bjorklund <mbj@tail-f.com> wrote:

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


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





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