> > The fix then becomes removing this change, and changing a pair of
> > writeText() calls to writeData(), in PropFindMethod.java (the logical
> > place - the slide core shouldn't know about the output format of the
> > data, and doesn't in other places). If you agree, I'll commit this
> > change (just doing some testing on it now).
>
> A followup to my own mail, after some quick testing:
>
> My approach doesn't work (at least with microsoft web-folders). This is
> because it applies to all the properties, and some of these are
> apparently treated specially. Having the resourcetype property not be
> <collection/> (exactly. Putting it in a CDATA section is too big a
> change, apparently) for a directory seems to break MS web-folders.
I tried that before (use writeData everywhere), but it's not a good idea to
do that when the property value is an XML node.
More generally, WebDAV makes the implicit requirement that a property value
is valid XML. I would be considering adding (and enforcing) this requirement
for Slide.
I think we can come up with something nice eventually.
Here's an option : setProperty could parse the property value to check if
it's a valid XML fragment, and wrap the value with a CDATA if it turns out
it's not.
> So I see that the problem is a bit bigger. Your way works, but seems
> rather like an ugly hack to me. If we can come up with a better
> solution, that'd be good. That would probably end up having to be a
> special treatment of displayname (to put it in a CDATA section) in
> PropFindMethod.java
>
> For now, I'll leave things as-is, and leave the decision up to you.
Remy
