Re: subtree filtering question

[Martin Bjorklund <mbj@tail-f.com>]

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



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