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

From: [email-masked]
Date: Fri, 18 Jun 2004 11:43:47 +0300

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 17.June.2004 13:47
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] XCAP Issue 7 Interim Summary: uniqueness in
> intermediatehops
> 
> 
> 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.
> >> 
> >> 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.
> 
> 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?

Why deal with the failure case when we can eliminate it?

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

We already have restrictions on what the XML schema should look like to be XCAP friendly. This is just another one.

> 
> 
> > 
> > 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>.
> 
> Right. In none of the proposals on the table would you be 
> able to modify 
> baz if a document looks like this.

So the proposal was to disallow such schema design.

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

btw, can <baz> be modified using positional selection, like this:

/foo/bar[1]/baz

this, of course, requires the client to have a copy of the XML document.

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

Ok, I think I'm fine with it just being a guideline.

/Hisham

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Jun 2004 08:36:14 -0400

> Why deal with the failure case when we can eliminate it?

Because eliminating it will require more implementation complexity than 
not. To eliminate the real-time check, the xcap implementation needs 
additional meta-data about the schema, which it can use to verify that, 
upon receipt, the URI is using a unique index at each hop. Implementing 
such a meta-data feature will be more work than just checking the 
document instance, since you need to go through the document instance 
ANYWAY.

> We already have restrictions on what the XML schema should look like to be XCAP friendly. This is just another one.

No, there is a HUGE difference.

The xcap guidelines are just that - guidelines. You can still manage any 
XML compliant document with xcap; you may just end up reading/writing 
the whole thing at once. But it works.

Thats radically different from saying that XCAP can ONLY manage 
documents whose schemas meet this criteria. If that is the case, we 
could not ever manage things like CPL documents, which dont have this 
property of uniqueness at each element.

> this, of course, requires the client to have a copy of the XML document.

Yes, this is possible.

> Ok, I think I'm fine with it just being a guideline.

OK, great.

-Jonathan R.