Subject: RE: subtree filtering question

From: Li Yan <[email-masked]>
Date: Wed, 28 Feb 2007 15:51:27 +0800

Hi,
I have reviewed the following discussion.
I found that Andy's answer conflict with the example in 6.4.7 of rfc4741.
Section 6.4.7 says:
   The "barney" subtree filter contains three containment nodes
   (<users>, <user>, <company-info>), two content match nodes (<name>,
   <type>), and one selector node (<dept>).  The subtree selection
   criteria is not met because user "barney" is not a "superuser", and
   the entire subtree for "barney" (including its parent <user> entry)
   is excluded from the filter output.

Should the empty <user> node be removed?

/Yan
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andy Bierman
> Sent: Friday, May 12, 2006 5:09 AM
> To: Martin Bjorklund
> Cc: [email-masked]
> Subject: 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 <[email-masked]> 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 [email-masked] 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 [email-masked] 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 [email-masked] 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 [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: Wed, 28 Feb 2007 10:58:42 +0100 (CET)

> I found that Andy's answer conflict with the example in 6.4.7 of rfc4741.

This was a discussion which was resolved later.

> Should the empty <user> node be removed?

Yes.

/martin