xml-add_ns: properly handle namespace definition w/o prefix

[ksmurchison]

More correct fix for #4489. Supersedes #5003

[dilyanpalauzov]

Will this work when the same prefix is overwritten for a child, like this PROPFIND request:

<D:propfind xmlns:D='DAV:'>
 <D:prop>
   <D:calendar-color xmlns:D="http://apple.com/ns/ical/"/>
   <D:calendar-color/>
 </D:prop>
</D:propfind>

?

[ksmurchison]

Will this work when the same prefix is overwritten for a child, like this PROPFIND request:

<D:propfind xmlns:D='DAV:'>
 <D:prop>
   <D:calendar-color xmlns:D="http://apple.com/ns/ical/"/>
   <D:calendar-color/>
 </D:prop>
</D:propfind>

?

Is this even valid XML?

[dilyanpalauzov]

Why should it be invalid XML? Everywhere the empty string can be used as namespace prefix, some other string can be used on this place as prefix, too.

[ksmurchison]

In the example above it states that D: is for DAV. Then you have a single property that defines D: to something else for its our purpose. I'm questioning whether that is legal and/or would any sane client actually do that.

[dilyanpalauzov]

I think my example is legal. Irrespecitive of this, the next example should undoubtfully be valid. Will your change work for PROPFIND?

<propfind xmlns='DAV:'>
 <prop>
   <D:uu xmlns:D="http://abc.de/ef/ghi/"/>
   <D:calendar-color xmlns:D="http://apple.com/ns/ical/"/>
   <calendar-color/>
 </prop>
</propfind>

[ksmurchison]

@dilyanpalauzov Yeah. Good point. I'm going to close this and will ask you to extend the Caldav:calendar_setcolor test to include the set of problematic PROPFINDs in your #5003 PR