jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: DM Rule #6: Files are Files are Files.
Date Tue, 30 Oct 2007 11:10:51 GMT
David Nuescheler wrote:
> Hi guys,
> 
>> Whether or not custom properties should live on nt:file or nt:resource
>> gets discussed regularly and I think it's fair so say that there is no
>> standard way to do that.
>> For instance, if your data model is file system like (folders and files
>> + metadata), such as in WebDAV, it definitively makes sense to have the
>> underlying properties both on the nt:folder and nt:file (thus
>> nt:hierachicalNode) nodes, and to use nt:resource only for metadata of
>> the binary content (such as mime type, encoding and so on).
> Personally I believe that there are a couple of reasons not to do that.
> 
> I believe that the nt:resource node should be viewed as the true
> container of the "meta-"information while nt:file is a shell containing
> the filename (or the "directory entry" in fs-speak).

Which would beg the question, why we don't have a jcr:children sub node 
on nt:folder then?

> So let's say I have an "author" or a "keywords" property on a pdf document
> that was extracted from the binary resource, then this information should
> definitely live on the extended nt:resource node, so if the nt:resource node
> is ever moved (let's say to a different nt:file container) the meta information
> travels with that node.

I would just move the nt:file. Where's the point in moving the sub node? 
In particular, many implementations that just expose files will not be 
able to do that, because the nt:resource child node is a computed node 
with no direct counterpart in the underlying storage.

> In addition to that there are practical reasons around the JCR query.
> Let's say i would like to find all the "pdf-documents" where the "author"
> property is set to "david" that contain "jcr", this works very nicely if
> you have your properties on the nt:resource node, and doesnt work
> if you have them on nt:file.

It does work with Jackrabbit (XPath being extended), and will work in 
JCR 2.0, so I'm less worried about that than before :-)

> But as Julian said, this is debated regularly.
> I must admit though that I have never understood the argument
>>from the "other side" ;) ...and that's why in my model the meta properties
> always live on nt:resource.

The main argument is (IMHO) that moving the properties down creates a 
very artificial special case for folder nodes, without any real benefit.

Best regards, Julian

Mime
View raw message