jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: properties with XML-Values; patch
Date Wed, 20 Feb 2008 23:19:41 GMT
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>&lt;a&gt/></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

Mime
View raw message