Subject: What is a tuple (was RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57])

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

If you want my opinion about the tuple issue, I think we should reverse the decision that was make providing flexibility on how to represent presence information in a tuple. We should on a single way to.

We can display all the options to the SIMPLE community and take a poll/vote. Rough consensus will give us an indication which one will it be.

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

---

From: [email-masked]
Date: Tue, 2 Sep 2003 16:52:51 +0300

(making what I said more readable)

If you want my opinion about the tuple issue, I think we should reverse the decision that was made that provides flexibility on how to represent presence information in a tuple. We should agree on a single way to represent this info.

We can provide all the options to the SIMPLE community and take a poll/vote. Rough consensus will give us an indication which one will be chosen.

Regards,
Hisham

> From: ext [email-masked] 
> [mailto:[email-masked]]
> Sent: Tuesday, September 02, 2003 1:59 PM
> To: [email-masked]
> Subject: What is a tuple (was RE: [Simple] [Fwd: Re: NETCONF 
> WG meeting
> minutes for IETF #57])
> 
> 
> If you want my opinion about the tuple issue, I think we 
> should reverse the decision that was make providing 
> flexibility on how to represent presence information in a 
> tuple. We should on a single way to.
> 
> We can display all the options to the SIMPLE community and 
> take a poll/vote. Rough consensus will give us an indication 
> which one will it be.
> 
> Regards,
> Hisham
> 
> 07054-2711

---

From: [email-masked]
Date: Tue, 2 Sep 2003 16:52:51 +0300

Regards,
Hisham