roots wasRe: filtering problem

["tom.petch" <cfinss@dial.pipex.com>]

This may relate to something that has been bugging me.

XPath is - at times - specified in terms of a root, and an XML document has a
single root element.  What is on the wire is an XML document but the datastore
is not - as Andy has pointed out before.

So what is an XPath filter being applied to?  The event as it would appear on
the wire as an XML document?  A conceptual document created in the datastore for
the purposes of filtering?  And if the latter, should we - we should! - specify
a root, either for the purposes of the examples or else for everything.

RFC4741 is quite discursive about roots but the notification I-D is silent; I
think that this last needs to change.

Tom Petch

----- Original Message -----
From: "Martin Bjorklund" <mbj@tail-f.com>
To: <ietf@andybierman.com>
Cc: <netconf@ops.ietf.org>
Sent: Friday, July 13, 2007 4:43 PM
Subject: Re: filtering problem


> Andy Bierman <ietf@andybierman.com> wrote:
> > Hi,
> >
> > There is another problem with filtering and the examples in sec 5: (!!!)
> >
> > The draft must say exactly where in the <notification> element
> > that the <filter> is applied.  The current text does not say anything.
>
> Agreed.
>
> > All the examples in sec. 5 are broken because the 'notification type'
> > layer is missing.
>
> I think it is ok.  Specify that the filter is applied to the
> 'notificationContent' element as root (which is the abstract element).
>
> > The examples assume the filters can only be
> > applied to a conceptual datastore, just like the <rpc> filter.
> >
> > However, the most commonly needed filter is going to be
> > on the notification type itself!
> >
> > Example (w/o namespaces):
> >
> >    <notification>
> >      <configChange>
> >         <configChangeTime>date-time string...</configChangeTime>
> >         <configChangedBy>fred@example.com</configChangedBy>
> >         <configTarget>/interfaces/interface[name='eth0']</configTarget>
> >          ...
> >      </configChange>
> >    </notification>
> >
> > For simplicity, assume the manager just wants
> > this one notification type. The filter is going to be something like:
> >
> >   <filter type="subtree">
> >     <configChange/>
> >   </filter>
>
> Yes, and IMO this is consistent with the examples.
>
>
> /martin
>
>
>
> > A filter for configChange just on a specific configTarget might be:
> >
> >   <filter type="subtree">
> >     <configChange>
> >       <configTarget>/interfaces/interface[name='eth0']</configTarget>
> >     </configChange>
> >   </filter>
> >
> > The way the draft is now does not reflect how notifications are
> > actually structured.
> >
> >
> > Andy
> >
> >
> >
> >
> > --
> > 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/>