Subject: RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]

From: [email-masked]
Date: Wed, 24 Sep 2003 18:09:15 +0300

Lets try to simplify those xpath expressions a little more, see below

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, September 19, 2003 6:25 AM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes 
> for IETF #57]
> 
> 
> [email-masked] wrote:
> Thanks for the examples. The expressions are clearly far from 
> obvious. I 
> wonder if we can constrain the type of operations that we want to 
> perform with presence tuples and express those operations 
> more directly. 
> The operations seem to be:
> 
> - create a presence document that consists of tuples where 
> attribute X 
> has value Y
> 
> - create a presence document that consists only of elements 
> A, B, and C 
> within <status>
> 
> (and combinations thereof)
> 
> Are there others that make sense?
> 
> I can see that for filtering random event documents, the 
> Xpath model may 
> be unavoidable in its proposed generality, but there seems to 
> be a large 
> danger of having filter specs create invalid presence documents by 
> providing access to 'raw' Xpath. Thus, I wonder if a simpler 
> description 
> that is restricted to presence documents (and is guaranteed not to 
> create invalid presence documents) wouldn't be helpful in practice.
> 
> 
> > Let me give you some examples:
> > 
> > - A watcher wishes to get the tuple that has a <class> 
> element with value "IM". The watcher has to either explicitly 
> list all the elements that can appear in a tuple that it 
> wants to receive, or alternatively, it tells the PA to 
> deliver the tuple that has element <class>IM</class> with all 
> the other elements that appear in that tuple. Its like using 
> a key for selecting a whole tuple. The latter can be achieved 
> using the following expression:
> > 
> > //*[rpid:class="IM"]/descendant-or-self::*

In the filter document, we can have something like this:

<condition>//class="IM"</condition>  !!this is an simple xpath expression, it returns true or false
<include>//class</include>
<include level="ancestor">//class</include> !!this says include tuple, it does not include the root element.
<include level="descendant">//class</include>
<include level="sibling">//class</include> !! sibling also means descendants of the siblings

The combination of ancestor, descendant and sibling will give you the whole tuple.

> > 
> > 
> > This actually selects the whole tuple only. if the watcher 
> wants to select the tuple and the root element <presence>, 
> you would do something like:
> > 
> > //*[rpid:class="IM"]/descendant-or-self::*  | 
> //*[rpids:label="im"]/ancestor::*
> > 
> > 
> > - The following is an example of how you can ask a PA to 
> include all tuples that are not of <class> IM:
> > 
> > //*[rpid:class="IM"]/following::* | 
> //*[rpid:class="IM"]/preceding::*

<condition gate="not">//class="IM"</condition>  !!probably need a better way to express a false condition than using the gate="not"
<include>//class</include>
<include level="ancestor">//class</include>
<include level="descendant">//class</include>
<include level="sibling">//class</include>

> > 
> > - A watcher asks the PA to deliver a tuple that has a 
> <basic> status of "closed", but it only wants the elements 
> that are not <status>
> > 
> > //*[basic="closed"]/following-sibling::* | 
> //*[basic="closed"]/preceding-sibling::* | 
> //*[basic="closed"]/ancestor::tuple

<condition>//basic="closed"</condition>
<include>//class</include>
<include level="ancestor">//basic</include> !!this says include tuple and presence elements
<include level="descendant">//basic</include>
<include level="sibling">//basic</include>
<exclude>//status</exclude>

I had to introduce <exclude> here.

You might be asking why do we have ancestor, descendant and sibling in every filter example above? Can't we generalise all three in one? Well, let me give you examples where I would only use one of them:

<condition>//tuple[@id="1234"]</condition>
<include>//tuple</include>
<include level="descendant">//tuple</include>

This chooses the tuple with id 1234 and its descendants

Henning expressed the concern about producing an invalid xml document. I think the PA should do the checking and either reject or terminate the subscription.

Regards,
Hisham

> > 
> > 
> > Again, this is if you don't want to indicate explicitly all 
> the elements that you want.
> > 
> > /Hisham
> > 
> >>>- selecting descendents: descendent:: , descendent-or-self::
> >>>- selecting ancestors: ancestor:: , ancestor or self::
> >>>- selecting siblings: following-sibling:: , preceding-sibling::
> >>>- selecting following and preceding elements: following:: , 
> >>
> >>preceding::
> >>
> >>
> >>
> >>
> >>
> 
> 
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple