Subject: AW: [Geopriv] Re: xcap, common-policy and geopriv-policy

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 30 May 2005 11:30:14 +0200

hi aki, 

it seems that the identity element is very important for you and you would like to address the xcap limitations particularly for the <id> element and other elements that have a child element using <id>. 

the fact that the same problem arises with other elements does not seem to scare you. 

i was wondering why you mention the aspect of uniqueness. the <id> element is not a key for the rule (it is actually an optional element). 

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Aki Niemi
> Gesendet: Donnerstag, 26. Mai 2005 16:09
> An: Guenther, Christian
> Cc: [email-masked]
> Betreff: [Geopriv] Re: xcap, common-policy and geopriv-policy
> 
> 
> Hi,
> 
> Inline.
> 
> ext Guenther, Christian wrote:
> > Hi,
> > 
> > with respect to the xcap issue of the common-policy schema, Jonathan
> > suggested (April 19)
> > to fix the problem either
> > 
> > 1) by transferring the element content into the value of an 
> attribute, 
> > or
> > 2) by adding to the element an attribute whose value 
> distinguishes the
> > element from elements of the same name.
> > 
> > For example, <id>[email-masked]</id> should then be 
> replaced by either
> > 
> > 1) <id nai="[email-masked]"/>,
> > or
> > 2) <id val="1">[email-masked]</id>.
> > 
> > As far as I can see, proposal 1) works well as long as the 
> element in
> > question (<id>) does not have child elements.
> 
> As it shouldn't. If it did, then you at least need 
> conditional updates.
> 
> > In the geopriv-policy
> > schema, however, we have the geospatial-loc-condition element, for
> > instance, which can be the root of the element tree
> > 
> > <geospatial-loc-condition>
> > <polygon>
> > <point>
> > <lat><lon>.
> > 
> > Suppose there are two such instances of the 
> geolocation-loc-condition
> > element in the conditions part of a given rule and xcap is 
> supposed to
> > select one of them. According to proposal 1), we had to 
> transform the
> > entire element tree into the value of an attribute in some way.
> > Therefore, I prefer proposal 2), since then we could simply 
> write down
> > 
> > <geospatial-loc-condition val="1">...</geospatial-loc-condition> and
> > <geospatial-loc-condition val="2">...</geospatial-loc-condition>,
> > 
> > so that xcap could easily select one of the two 
> geospatial-loc-condition
> > elements. 
> 
> I think this is far less important in these kind of cases. 
> Sure the val 
> attribute provides a key, but it isn't naturally a unique one 
> (like the 
> identity is). Therefore, you still need a local copy to determine the 
> value of this attribute in order to select the appropriate condition 
> using the val attribute as the node selector.
> 
> You couldn't just "blindly" remove a condition because the 
> handle is a 
> random one. Unless you're suggestion is to always order these 
> elements 
> so that the val actually represents the position of the element, then 
> you end up wasting many more round trips in ordering than potentially 
> you might save as a result of it.
> 
> However, I could see a similar need for the <domain> and the 
> <id>s under 
> <except> elements. These also have the necessary uniqueness 
> to serve as 
> a handle.
> 
> Cheers,
> Aki
> 
> > 
> > 
> > Christian
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Aki Niemi
> > Sent: Mittwoch, 18. Mai 2005 15:39
> > To: Tschofenig, Hannes
> > Cc: [email-masked]
> > Subject: Re: [Geopriv] revised identity text
> > 
> > 
> > Hi All,
> > 
> > Hannes asked me to summarize an issue that was sent to the 
> SIMPLE WG 
> > about common-policy. This is an issue in the context of 
> manipulating 
> > common-policy rules using XCAP.
> > 
> > The problem is that XCAP only allows selection (and 
> therefore addition, 
> > removal and modification) of nodes based on element name, 
> attribute and 
> > position. It doesn't support selection based on element content. 
> > Therefore selecting <id> elements within the <identity> seems 
> > unnecessarily hard, since the rule maker always needs an 
> up-to-date copy
> > 
> > of the <identity> element to find out the position of the 
> correct <id> 
> > to be selected.
> > 
> > To fix this, there has been a proposal to tweak the <id> 
> element such 
> > that instead of:
> > 
> > <id>[email-masked]</id>
> > 
> > it becomes:
> > 
> > <id value="[email-masked]" />
> > 
> > Selecting this element is much easier in XCAP simply using 
> the attribute
> > 
> > value as the node selector, and also seems like a minor change to 
> > common-policy schema.
> > 
> > Cheers,
> > Aki
> > 
> > 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

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