Subject: RE: [Simple] XCAP Issue 6 Interim Summary: selecting elements by textvalue

From: [email-masked]
Date: Mon, 5 Jul 2004 16:38:47 +0300

If I have an authorisation rule as follows:

    <cr:rule id="1">
     <cr:conditions>
      <cr:identity>
       <cr:domain>example.com</cr:domain>
       <cr:except>[email-masked]</except>
       <cr:except>[email-masked]</except>
      </cr:identity>
     </cr:conditions>
     <cr:actions>
      <sub-handling>allow</sub-handling>
     </cr:actions>
     <cr:transformations>
      <provide-tuples>
       <all-tuples></all-tuples>
      </provide-tuples>
      <provide-activity>
        <tuples-whose>
          <ts:class>friend</ts:class>
        </tuples-whose>
      </provide-activity>
     </cr:transformations>
    </cr:rule>

Now I want to remove the first <except> that excepts Bob. How do I do that without selecting the element by text value? I'm going to have to re-write the whole <identity> element and its sub elements. Is that acceptable?

Thanks,
Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 10.June.2004 09:42
> To: Simple WG
> Subject: [Simple] XCAP Issue 6 Interim Summary: selecting elements by
> textvalue
> 
> 
> The issue here was whether or not to include a feature in xcap that 
> allowed you to select an element by the value of its content. For 
> example, if the doc is this:
> 
> <foo>
>    <bar>val</bar>
>    <bar>ue</bar>
> </foo>
> 
> then you could do foo/bar[.="val"] and this would select the 
> first bar 
> element.
> 
> The problem, raised by Joel on the list and discussed at the 
> meeting, is 
> that this makes sense only if the text content is actually a useful 
> index. In some application usages, the text content may be text for 
> human consumption, like a paragraph of text (think about the 
> <t> element 
> in xml2rfc). Indexing this is expensive and a waste of time.
> 
> I proposed three possible solutions:
> 
> 1. add more complexity to the spec - allow applicaiton usages to 
> declare, in their definitions, when text content represents 
> an index. An 
> implementation would therefore be able to be dynamically 
> programmed to 
> know which element content to index.
> 
> 2. Allow selection of elements based on content; assume that 
> URIs would 
> not use content as a selector unless it really was a useful index
> 
> 3. do not allow selection based on content
> 
> 
> 
> The question was raised as to whether there was a specific 
> application 
> usage driving this feature. There isn't. There was general 
> agreement to 
> only add stuff if a concrete need in an existing application 
> usage was 
> driving it. Since it was not the case here, there was 
> consensus to drop 
> this feature.
> 
> Any objections?
> 
> Thanks,
> 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
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 05 Jul 2004 21:04:24 -0400

There are a number of choices. Assuming the current schema:

1. replace the whole of identity
2. if the client has the document cached, it can use positional 
addressing to delete the specific <except> element

The current schema (as in 
http://www.tschofenig.com/snapshot/draft-ietf-geopriv-common-policy-01_20June2004.txt) 
allows for multiple <id> elements within identity. If we want the 
ability to add and remove those individually, without replacing the 
whoel thing, and we want the ability to do this without caching the 
document, the best approach is to update the schema so that instead of this:

<id>sip:user@domain</id>

it would be this:

<id uri="sip:user@domain/>

It would be my suggestion to allow this, since I do expect this to be a 
common case.

Hannes - would it be OK to make this change in the schema?

Thanks,
Jonathan R.