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

From: [email-masked]
Date: Thu, 18 Sep 2003 17:44:17 +0300

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, September 17, 2003 11:05 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes 
> for IETF #57]
> 
> 

> 
> > Supported
> > ---------
> > Note: any combination of these is possible
> > - selecting root element: /
> > - selecting all elements: //
> 
> Does this include things like 'element named <status>'?
> 
> > - selecting all enclosed elements: *
> > - selecting attributes: @
> > - selecting elements using attributes as keys: [@x]
> > - selecting element using attribute and its value as key: [@x='y']
> 
> Can you give a use case for the ones below?

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::*

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::*

- 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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Sep 2003 23:25:02 -0400

[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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Sep 2003 23:25:02 -0400

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Sep 2003 17:12:09 -0400

> perform with presence tuples and express those operations more directly. 

I would also like to explore this avenue.

It seems to me that fairly complex xpath expressions, like the ones 
Hisham posted, would be needed to cause filtering or auth policies to 
result in the desired document. My concern is not that the operation 
these perform isn't "obvious" to a person. Rather, its performance. We 
are going to be a big tax in XML manipulations in order to make a set 
of changes to a presence document, which could have been enumerated 
and explicitly supported ahead of time. I dont think that, at this 
point in time, the generality is worth the performance it will 
probably cost.

> Are there others that make sense?

The current xcap auth document allows a few more:

* create a presence document that has everything but the contact 
address (so users can see your status but can't contact you per se)

* making the above two items conditional on the value of a specific 
element A within <status>

* create a presence document that consists only of elements A, B, C 
which come from the specified set of XML namespaces

* create a presence document that has elements A, B, C only if they 
have the specified values

> create invalid presence documents) wouldn't be helpful in practice.

There is also the performance issue with xml manipulations that I am 
really worried about. Practically speaking, I suspect many 
implementations will not actually STORE the presence data internally 
in XML format. Rather, they will have highly optimized internal 
representations commensurate with the set of supported manipulations 
on that data.

If this is done, implementing a filter requires the encoding of that 
internal data into a full presence document, followed by Xpath 
processing, followed by a discard of the data that doesnt match. It 
would be much more efficient to discard data first while its still in 
the raw format, and THEN encode into XML. That can only be done when 
the authorization and filtering policies are expressed semantically, 
rather than as syntactic transformations on the final XML document.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Sep 2003 17:12:09 -0400

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Sep 2003 21:57:45 -0400

Jonathan Rosenberg wrote:

>> - create a presence document that consists only of elements A, B, and 
>> C within <status>
>>
> * create a presence document that has everything but the contact address 
> (so users can see your status but can't contact you per se)

This seems a special case of the 'everything-except' rule. This doesn't 
require xpath, just an element name (with name-space).

> element A within <status>

That's part of the conditional part (see the geopriv discussions).

> which come from the specified set of XML namespaces

A generalization of the selection above.

> 
> * create a presence document that has elements A, B, C only if they have 
> the specified values

Again, separate issue - selection.

> implementations will not actually STORE the presence data internally in 
> XML format. Rather, they will have highly optimized internal 
> representations commensurate with the set of supported manipulations on 
> that data.

I've tried to make this point at the GEOPRIV interim meeting and 
suggested that we test any rule language on whether an SQL-like language 
could be used to implement it. This doesn't mean that people will use 
SQL (although this is more reasonable than traversing and processing raw 
XML for each presence update), but it does mark a particular regimen of 
complexity that is well-understood and known to scale to large data sets 
and large transaction volumes. In particular, it implies a relatively 
flat rather than tree-shaped data model within each tuple.

Another way of looking at this is that we should be able to write rules 
as a table, not as an arbitrarily nested program.

> the raw format, and THEN encode into XML. That can only be done when the 
> authorization and filtering policies are expressed semantically, rather 
> than as syntactic transformations on the final XML document.
> 
> 
> -Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Sep 2003 21:57:45 -0400