Subject: [Simple] XCAP Issue 7 Interim Summary: uniqueness in intermediate hops

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jun 2004 03:12:13 -0400

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. 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