RE: [Simple] XCAP and its problem with Namespaces caused by usingonly the XML fragment body.

Jari makes a very good point.  His is a practical solution that will work with no changes required.  I'd agree that the problem isn't one worth solving.

> 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

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]