Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using only the XML fragment body.

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Oct 2005 00:28:38 -0400

since this was recently referenced, I wanted to follow up on a couple of 
specific points:

Hyttfors, Per wrote:

> Comments inline.

>>Some other thoughts are:
>>
>>1. an xcap extension that allowed to specifically query for 
>>the namespace bindings in scope for a particular element
>>
> 
> 
> If this can be done within the original request (is that alternative 2?)
> I think it has value. In case it would require a client to make two
> requests it seems to make more trouble than it solves. I suppose that
> the second request also would need to be conditional to safely assure
> that the data and prefixes weren't changed since the initial element
> fetch.

This is what is now written in xcap-08. It requires two requests; at 
least, one to get the namespace bindings, and one to do the update. You 
can cache the bindings, but then you run into problems if they have 
changed when you do an update.

> 
>>2. change xcap so that what is returned is an xml fragment 
>>that includes additional information on the namespace bindings in scope
>>
> 
> 
> W3C dealt with this problem years ago and came up with their XML
> fragment entity. It is already a working standard and there has to be
> several implementations already using this.

I looked at it recently, though not really during the design of xcap 
itself. The main problem I had is that they never got around to 
specifying a consolidated format that included both the fragment context 
and the body. Thus, to use this with GET, we'd have to either go to 
multipart or define our own consolidated format. Same with PUT, except 
the added ugliness that when you do a PUT, youre not really putting the 
fragment and its context; you really ARE putting just the body.

> 
> Another W3C standard that seems to deal with exactly the problems you
> get when maintaining XML documents on a server is Exclusive XML
> Canonicalization. To me this seems to be an ideal solution for us. The
> fragment will simply inherit all the required namespace bindings and
> include them as if it was part of the fragment.

OK, I took a look at this spec. If I understand what it means, the 
topmost element would contain namespace declarations for only those 
namespace prefixes used in its children. That helps the GET case,  but 
not the PUT case. If you PUT such a canonicalization, it would require 
munging of the namepsace prefixes before insertion into the document, 
with the problems that come with that.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 26 Oct 2005 15:25:32 +0300

ext Jonathan Rosenberg wrote:

> since this was recently referenced, I wanted to follow up on a couple 
> of specific points:
>
> Hyttfors, Per wrote:
>
>> Comments inline.
>>
>>
>
>>> Some other thoughts are:
>>>
>>> 1. an xcap extension that allowed to specifically query for the 
>>> namespace bindings in scope for a particular element
>>>
>>
>>
> least, one to get the namespace bindings, and one to do the update. 
> You can cache the bindings, but then you run into problems if they 
> have changed when you do an update.
>
>
>
>>
>>> 2. change xcap so that what is returned is an xml fragment that 
>>> includes additional information on the namespace bindings in scope
>>>
>>
>>
> specifying a consolidated format that included both the fragment 
> context and the body. Thus, to use this with GET, we'd have to either 
> go to multipart or define our own consolidated format. Same with PUT, 
> except the added ugliness that when you do a PUT, youre not really 
> putting the fragment and its context; you really ARE putting just the 
> body.
>
>
>>

The whole issue (if there's any) has no influence on my reference 
implementation as I don't have any cases where I needed these "blind" 
updates. I have found it extremely difficult to write an application 
that doesn't break easily when you'll try to do "blind" xcap patching. 
There are imo quite rare cases where it can/could be used. So the whole 
discussion is imo quite obscure.

However, if an application wants to try this "blind" patching  (==put 
with some qualified elements) why just simply add those declarations on 
the payload. Sure it leads to additional ns declarations on the server, 
but who cares. There's no ambiquity with the canonical format, because 
those addiotional ns declarations are then removed anyway. (and I 
certainly don't want that the server is required to remove those ns 
declarations during xcap put patching, no).

Perhaps I'm a lousy programmer but to me this is a no-issue or at least 
largely exaggerated one. Also having some mandated prefixes is a bad 
idea, imo. In addition, it looks like that there must be another 
application that first has created the doc, and now your app has to edit 
it (as if as your app doesn't know what it is doing, right ?). So is 
this really this big issue ? E.g. I am personally much more worried 
about the case where you'll have many apps editing the same doc, as 
you'll have no locks in xcap (== not a proposal to add one, no)
 
And btw. regarding to the original example from Per, xcap-list should 
have reused imo the same namespace declaration for lists and services...

br,
Jari

---

From: Sebastian Ley <[email-masked]>
Date: Thu, 27 Oct 2005 16:15:34 +0200

* Jari Urpalainen wrote:

> E.g. I am personally much more worried

Well, at least singleton commits can be protected with an HTTP If-Match. This 
is no replacement for transactions, but I had not the impression that this 
was in scope for XCAP...

Regards,
Sebastian

-- 
Blog: http://www.withouthat.org/~sebastian/blog
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6