Subject: RE: [Simple] XCAP Issue 7 Interim Summary: uniqueness in intermediatehops

From: [email-masked]
Date: Thu, 10 Jun 2004 16:11:35 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 10.June.2004 10:12
> To: Simple WG
> Subject: [Simple] XCAP Issue 7 Interim Summary: uniqueness in
> intermediatehops
> 
> 
> This is an issue raised by Joel and discussed on the list. 
> The problem 
> was whether or not we would require the URI to select a 
> unique element 
> at each hop of its evaluation, or just make sure the final result of 
> selection was unique.
> 
> If you are implementing XCAP without an XPATH library, this 
> is a really 
> nice feature to have. There is code and computational 
> complexity if its 
> not there. If you have an XPATH library, its a constraint 
> that you need 
> to explicitly verify outside of the xpath library, since XPATH does 
> allow non-uniqueness at each hop.
> 
> There were continuing objections to the complexity introduced if each 
> hop is not unique. As such, there was consensus on the uniqueness 
> requirement.
> 
> However, Henning had a proposal to take this a step further. His 
> proposal was that we could constrain XCAP so that at each 
> step, you were 
> selecting an element based on a unique index that was declared by the 
> application usage to be unique. This way, you couldn't even 
> ever have an 
> expression which selected multiple things at each step. Here's an 
> example to explain. Lets say we've got a schema that has a parent 
> element called <foo>, and <foo> can have one or more children, each 
> named <bar>. So, the following is a valid document:
> 
> <foo>
>    <bar/>
> </foo>
> 
> And thus, the expression "foo/bar" selects the <bar> element, 
> and also 
> gives you a single element at each step. Thus, it would be valid. 
> However, in Hennings proposal, this expression would be 
> illegal, since 
> it might be the case that <bar> is not unique, and thus it 
> could be the 
> case that tbe expression "foo/bar" does not resolve to 
> something unique. 
> In such a case, the schema would have to mandate that each 
> bar element 
> have an attribute called "id" (for example), and that the application 
> usage would mandate that this attribute be unique amongst all 
> siblings. 
> If you do that, then you can be guaranteed that the expression:
> 
> foo/bar[@id="223"]
> 
> is unique. It may not point to anything, but if it does, it points to 
> only one element.
> 
> Henning, if I have mis-interpreted your proposal, let me know.
> 
> This proposal was further refined. The idea was that an 
> element needs to 
> have a unique index only if it can appear more than once in the 
> document. If it can appear only once, you don't need to 
> define a unique 
> attribute for it.
> 
> Upon further consideration, I concluded that the refined proposal was 
> not a good idea. The objective of what Henning was proposing 
> is that a 
> server could look at the URI, and without needing to know the 
> schema or 
> even the instance document, determine whether the URI resolved to 
> something unique. Of course, it could still resolve to nothing if any 
> one of the indices didn't exist in the instance document. With the 
> refined proposal, the server would need to know the schema to 
> determine 
> whether the URI was unique.

No it doesn't. The server can still do the dynamic checking of the instance document. Having refined proposal will aid in eliminating the possibility of failure.

eg: if we have

<foo>
   <bar>
      <baz>
   </bar>
   <bar>
      <xyz>
   </bar>
<foo>

then /foo/bar/baz expression is not unique at every step and therefore I can never ever modify <baz>.

If we define that "an element needs to have a unique index only if it can appear more than once in the document. If it can appear only once, you don't need to define a unique attribute for it", then the server can still do the dynamic checking (if it does not trust the client) and it enables the client to modify some parts of the instance document that are otherwise unmodifiable.

Regards,
Hisham

> That adds a lot of complexity; 
> you'd need to 
> plug some kind of meta-data about the schema into the xcap 
> server, so it 
> could figure out which elements were unique in the document, 
> and which 
> weren't. Thus, it would add more complexity than it would remove.
> 
> Indeed, for Henning's proposal to work, you'd need every 
> schema to have 
> the same attribute name as a unique index. For example, "id". 
> We'd have 
> to mandate that every document managed by XCAP, for each 
> element in that 
> document, have an attribute called "id" that's present in the 
> doc, so we 
> can use it as an index and guarantee its always there.
> 
> That eliminates the possibility of xcap managing existing 
> documents (for 
> example, PIDF). I think that is a costly result. Furthermore, 
> you STILL 
> need to parse through the document to determine if the URI points to 
> something or nothing. Once you've committed to doing that, the 
> additional cost of doing a dynamic check for unqiueness seems 
> trivial to me.
> 
> Thus, I'd propose that we stick with our original conclusion, 
> which is 
> to mandate that the XCAP expression evaluate to a unique 
> element at each 
> step. This constraint would be checked by the server 
> dynamically based 
> on the instance document.
> 
> Objections?
> 
> -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: Thu, 17 Jun 2004 06:47:27 -0400

inline.

[email-masked] wrote:

> 
>> -----Original Message----- From: [email-masked] 
>> [mailto:[email-masked]]On Behalf Of ext Jonathan Rosenberg
>>  Sent: 10.June.2004 10:12 To: Simple WG Subject: [Simple] XCAP
>> Issue 7 Interim Summary: uniqueness in intermediatehops
>> 
>> 
>> This is an issue raised by Joel and discussed on the list. The
>> problem was whether or not we would require the URI to select a 
>> unique element at each hop of its evaluation, or just make sure the
>> final result of selection was unique.
>> 
>> If you are implementing XCAP without an XPATH library, this is a
>> really nice feature to have. There is code and computational 
>> complexity if its not there. If you have an XPATH library, its a
>> constraint that you need to explicitly verify outside of the xpath
>> library, since XPATH does allow non-uniqueness at each hop.
>> 
>> There were continuing objections to the complexity introduced if
>> each hop is not unique. As such, there was consensus on the
>> uniqueness requirement.
>> 
>> proposal was that we could constrain XCAP so that at each step, you
>> were selecting an element based on a unique index that was declared
>> by the application usage to be unique. This way, you couldn't even
>>  ever have an expression which selected multiple things at each
>> step. Here's an example to explain. Lets say we've got a schema
>> that has a parent element called <foo>, and <foo> can have one or
>> more children, each named <bar>. So, the following is a valid
>> document:
>> 
>> <foo> <bar/> </foo>
>> 
>> And thus, the expression "foo/bar" selects the <bar> element, and
>> also gives you a single element at each step. Thus, it would be
>> valid. However, in Hennings proposal, this expression would be 
>> illegal, since it might be the case that <bar> is not unique, and
>> thus it could be the case that tbe expression "foo/bar" does not
>> resolve to something unique. In such a case, the schema would have
>> to mandate that each bar element have an attribute called "id" (for
>> example), and that the application usage would mandate that this
>> attribute be unique amongst all siblings. If you do that, then you
>> can be guaranteed that the expression:
>> 
>> foo/bar[@id="223"]
>> 
>> is unique. It may not point to anything, but if it does, it points
>> to only one element.
>> 
>> This proposal was further refined. The idea was that an element
>> needs to have a unique index only if it can appear more than once
>> in the document. If it can appear only once, you don't need to 
>> define a unique attribute for it.
>> 
>> Upon further consideration, I concluded that the refined proposal
>> was not a good idea. The objective of what Henning was proposing is
>> that a server could look at the URI, and without needing to know
>> the schema or even the instance document, determine whether the URI
>> resolved to something unique. Of course, it could still resolve to
>> nothing if any one of the indices didn't exist in the instance
>> document. With the refined proposal, the server would need to know
>> the schema to determine whether the URI was unique.
> 
> 
> No it doesn't. The server can still do the dynamic checking of the
> instance document. Having refined proposal will aid in eliminating
> the possibility of failure.

Once you have committed to do the dynamic checking of the document, why 
not just deal with the failure case? You already need to deal with the 
failure case that there may be no instances of an element, even though 
one is requested in a GET. Why is that harder than dealing with the case 
that there are more than one?

If you try and eliminate it by introducing rules into the structure of 
the document (that is, impose rules on the schemas for XCAP managed 
documents), you make it so that xcap can NEVER be used to manage 
documents whose schema doesn't match the requirements.

> 
> eg: if we have
> 
> <foo> <bar> <baz> </bar> <bar> <xyz> </bar> <foo>
> 

Right. In none of the proposals on the table would you be able to modify 
baz if a document looks like this.

> 
> If we define that "an element needs to have a unique index only if it
> can appear more than once in the document. If it can appear only
> once, you don't need to define a unique attribute for it", then the
> server can still do the dynamic checking (if it does not trust the
> client) and it enables the client to modify some parts of the
> instance document that are otherwise unmodifiable.

I don't understand. None of the proposals differ in terms of making it 
possible to modify something that isn't modifiable in one of the other 
proposals.

In the technique you are advocating, we would introduce this rule that 
an element can appear once in a doc, and if it appears more than once, 
has to have a unique index. This can be enforced by mandating that 
XCAP-managebale documents have to have schemas with this constraint. I 
think that is too limiting. Perhaps you are instead advocating that we 
don't introduce this constraint into the schema, but rather, instance 
documents. I still think thats too limiting. We may have documents that 
have two elements with the same name and no unique attributes, but there 
isn't a need to modify at that level; you would only be able to modify 
the document by addressing elements that are ancestors of the pair. 
Thats fine. So, I'm saying, allow documents to look this way, but you'll 
get an error if you try and address below this point in the document 
where the pair exists. Of course, if there is only one element with the 
name in the document, you can address deeper. In your proposal, you are 
just trying to eliminate the case where a document ever has two elements 
with the same name and non-unique attributes; in the approach I prefer, 
you allow the case but don't allow addressing below that level. In 
neither case can you address into a document below a set of 
non-uniquely-identifiable elements.

I think its fine to have a guideline which recommends that a client 
needs to use unique attributes when creating documents where it wants to 
address those elements or below. But, this is nothing more than a 
guideline.

-Jonathan R.