 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
8 messages in org.apache.jackrabbit.usersRe: DM Rule #6: Files are Files are F...| From | Sent On | Attachments |
|---|---|---|
| David Nuescheler | Jul 7, 2007 4:29 am | |
| Tako Schotanus | Jul 10, 2007 4:37 am | |
| fmandelbaum | Oct 29, 2007 1:06 pm | |
| Julian Reschke | Oct 30, 2007 12:37 am | |
| David Nuescheler | Oct 30, 2007 3:13 am | |
| Julian Reschke | Oct 30, 2007 4:10 am | |
| Felix Meschberger | Oct 30, 2007 4:11 am | |
| Fabián Mandelbaum | Oct 30, 2007 4:30 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: DM Rule #6: Files are Files are Files. | Actions... |
|---|---|---|
| From: | Julian Reschke (juli...@gmx.de) | |
| Date: | Oct 30, 2007 4:10:28 am | |
| List: | org.apache.jackrabbit.users | |
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