[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: subtree filtering question
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: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Friday, May 12, 2006 5:09 AM
> To: Martin Bjorklund
> Cc: netconf@ops.ietf.org
> 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 <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/>
--
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/>