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
