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

From: [email-masked]
Date: Tue, 2 Sep 2003 13:54:03 +0300

PIDF and tuple is just one example of where filtering would be used. The filtering mechanism that we are building is generic for all event notification packages.

There is an open issue in the tuple design team, and that is how a client can get information about the tuple construction at the server side.

Quoting Robert:
"There are still questions around the use of tuples to be discussed.
The one this design team was circling around whether a PA needs to
expose the policy it used to create tuples to the watcher and whether
a watcher needs to be able to request a certain policy. This discussion
will move back to the SIMPLE list." 

This is needed so that the watcher knows how to render the information to the user using GUI to the like.

Note, this is tuple specific issue. I don't think the filtering solution should be complicated just to satisfy the tuple problem, the tuple problem should be fixed instead.

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, September 02, 2003 8:38 AM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes 
> for IETF #57]
> 
> 
> It ties back into our ongoing debate about "what is a tuple". Its not 
> that the PIDF XML has no semantics, its that the underlying 
> "presence" 
> of a user can map into a variety of different XML documents, 
> depending 
> on the underlying policy of the PA and presentity. Thus, if 
> the desire 
>   is to have a filter that restricts geolocation inforamtion, the 
> appropriate XPath expressions depend a lot on how the PA chooses to 
> place the presence information into the presence document. As an 
> example, the PA may use it to compute the "placetype" RPID attribute. 
> Or, it may appear in some tuples, but not others. It may appear as a 
> textual piece of a note, i.e., "at work". Xpath cannot be 
> used to tell 
> a PA "don't put geoloc data anywhere in the document".
> 
> More abstractly, and in the context of Graham's note, I believe there 
> is an underling data model which has "raw" presence data, and then 
> this data gets encoded into presence documents using PIDF. I believe 
> filters are ultimately useful only in their application to this raw 
> data. Since there is a gap between the raw data and its encoding into 
> a PIDF document, the usage of Xpath expressions on the PIDF document 
> doesnt seem right to me.
> 
> Thanks,
> Jonathan R.
> 
> [email-masked] wrote:
> 
> > I don't buy it. Why would you define an XML schema who's syntax
> > does not match the semantics?
> > 
> > I earlier bought the argument that XPath is too complicated to
> > implement for a simple use case of just wanting to identify an
> > element in an XML document, and thereafter agreed to provide some
> > text in the I-D pointing to this issue and explaining the limited
> > use of XPath in filtering.
> > 
> > /Hisham
> > 
> > 
> >> -----Original Message----- From: ext Jonathan Rosenberg
> >> [mailto:[email-masked]] Sent: Friday, August 29, 2003
> >> 5:36 PM To: Simple WG; [email-masked] Subject: [Simple] [Fwd:
> >> Re: NETCONF WG meeting minutes for IETF #57]
> >> 
> >> 
> >> Graham Klyne posted this note on netconf that has some insights
> >> which I think can benefit us. Pay attention to this statement:
> >> 
> >> Graham writes:
> >> 
> >>> I would be very wary about using XPath as the basis for
> >>> selective access to XMLConf data.  XPath, by design, provides
> >>> selection on the syntactic structure of XML:  it has been
> >>> suggested elsewhere (e.g. in the netconf protocol document,
> >>> IIRC) that the data model is separate from the protocol
> >>> framework (which I think is a good approach).  But the
> >>> query/selection syntax should be related to the data model, not
> >>> to the carrier syntax.  I have seen difficulties arise with
> >>> different XML-based applications where people tried to use
> >>> XPath selection for an XML format used to carry a data model 
> >>> that was somewhat different from the XML carrier syntax.  If
> >>> the data model does not map directly onto the XML syntax, then
> >>> XPath selection may well prove inadequate to make appropriate
> >>> selection in the configuration data.
> >> 
> >> I think this summarizes nicely the concerns I have had about
> >> using xpath for filtering. I am also going to be removing it from
> >> element identification in the next xcap-auth rev.
> >> 
> >> -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
> >> 
> > 
> > 
> 
> -- 
> 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
> 
> 

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