jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Porath" <rol...@exari.com>
Subject RE: properties with XML-Values; patch
Date Wed, 20 Feb 2008 23:03:44 GMT


> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Wednesday, 20 February 2008 8:36 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: properties with XML-Values; patch
> 
> OK.
> 
> 1) So first of all, we have a bug in Jackrabbit's WebDAV:
> 
> When you set an XML-typed property, it persists some broken value,
> assuming it's a string. This needs to be fixed. If Jackrabbit can't
> store a property, the request needs to be rejected.

Yep

> 
> 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
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.
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.

> 
> Further comments:
> 
>  > Agree with that. Looking for a better way
> 
> See 2). Also, make sure to use namespace-aware DOM methods throughout.

Will do; currently I am mostly in the POC stage so there'll be a big
refactoring in the future; still it's very good to get feedback on the code
even at this stage; 

> 
> > You have to realise there's two issues here:
> > 1. persisting a property that has a string containing XML as a value;
> > Try
> > propset someresource xmlProperty
> >
> <propValue><subValue>valueOfSubValue1</subValue><subValue>valueOfSubValue2
> </
> > subValue></propValue>
> > in cadaver then do propget; it will look like this:
> > xmlProperty = [propValue: null]
> > so any xml string in a prop value is set to the value of [propValue:
> null];
> > I'd say this is a bug in jackrabbit or to be more specific in
> > WebdavRequestImpl.parsePropPatchRequest() irrespective of jackrabbit
> having
> > the concept of XML properties.
> 
> Yes, that's a bug. See above.
> 
> > 2. after patching WebdavRequestImpl I was able to persist a string
> > containing xml.
> > A propget request results in a response looking somewhat like this:
> > Someresponsestuff .....&lt;propvalue&gt;.....somemoreresponsestuff ONLY
> for
> 
> Now that happens because you have stored the XML as a string. PROPFIND
> has no way to decide which is which. It behaves completely correct here.
> 
> > properties I added. Derived properties like supportedlock were not html
> > encoded but plain xml
> > Someresponsestuff .....<lockEntry><lockscope>.... somemoreresponsestuff
> > This happens in the serialisation.
> 
> As I said before; these are computed on the fly, so they really do not
> matter here. (And, it's XML, not HTML).


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.
Ps: I am aware that the content is xml but it is html encoded.


> 
> > Now what the client makes of this is an entirely different matter;
> cadaver
> > does not care, Dav Explorer interprets plain xml as xml and encoded xml
> as a
> > plain vanilla string. I don't know who's right but most of our clients
> use
> > Dav Explorer so I gotta make it work.
> 
> If we make changes, what needs to work is the correct interpretation of
> the spec, not what a particular client supports.

Absolutely. 

> 
> If the server allows to PROPPATCH "foo" with
> 
>    <D:prop xmlns="DAV:"><foo><x/></foo></D:prop>
> 
> then the result from PROPFIND needs to be exactly that, not
> 
>    <D:prop xmlns="DAV:"><foo>&lt;x/&gt;</foo></D:prop>
> 
> > Methinks the heart of the matter is that jackrabbit is a bit confused as
> to
> > what to do with XML; on the one hand you say it has no concept of xml
> > properties which is fair enough. On the other hand it quite clearly has
> when
> > it comes to derived properties.
> 
> Those are special cases.
> 
> > Sorry bout being a bit unclear in the first post, I just thought the
> code
> > said it all;
> > Hope this clears matters up a bit
> >
> > Cheers
> > roland
> 
> BR, Julian
> 
> !DSPAM:47bbf4c8183761219414208!



Mime
View raw message