Roland Porath wrote:
2) How to decide that: assuming the PROPPATCH request has been parsed
into DOM objects, the right thing to do is to check whether the child
nodes of the property element (not the DAV:prop element) contain element
nodes. In that case, the property type is not plain text, and for now
can not be stored.
Does that not contradict rfc 2518? Chapter 14 has something to say about xml
It means that Jackrabbit can not do things that RFC2518 requires, yes.
But that's better than claiming to do it (allowing the PROPPATCH), and
then not doing it after all.
Besides, you really should be looking at RFC4918.
processing which I would interpret as being at odds with the behavior you
suggest here.
I think it's also necessary to keep in mind that for instance slide (server)
supports xml in properties. So it will create serious obstacles in the
migration path.
Yes. It's a problem. But there's no simple way to fix it, at least not
to me.
Plus all the clients I've looked at so far seem to support xml properties.
I'd say there's a bit of a fait accompli (pardon my french) here.
Actually, I've been in the business of supporting WebDAV clients and
servers for lots of years, and I haven't seen XML properties in practice.
I appreciate the fact that from the server's point of view they are
completely different animals. But the client has no way of knowing that nor
should it have that knowledge.
From a client point of view (only seeing the response) you get two different
kinds of "XML-ish" properties; one that's encoded, one that's not.
In terms of clarity and simplicity of the interface this does not help.
Unless of course there is a rationale for it that makes sense from a client
point of view (being hard to implement on the server is nothing the client
cares about). If however, there is such a reason it would need to be
documented because it is not immediately obvious.
Hope that makes sense.
Well, not really.
The issue is that Jackrabbit currently can't store XML-typed properties.
That's a conformance problem.
Your proposed patch does not solve it; for instance if a client actually
*does* set a property value to the string "<a/>" be sending a PROPPATCH
such as
<D:prop><foo><a>/></foo></D:prop>
then upon PROPFIND the system would return
<D:prop><foo><a/></foo></D:prop>
which clearly is a bug.
So while trying to fix one issue, you created a new one.
This is because you really can't fix this problem on the WebDAV layer
alone; you need to figure out a way to distinguish between properties
that are plain text, and those that need to be reparsed as XML.
Ps: I am aware that the content is xml but it is html encoded.
No, it's not. Really.
> ...
BR, Julian
