On 8/7/07, qcfireball <[EMAIL PROTECTED]> wrote: > > > I hope this provides you some clarity. > > In reply to Bob's question (his text omitted for brevity): > Here are 2 scenarios involving files. One involves a single file, the > other > an arbitrary number of files. The format of the text is: > node-type|node-name, with children underneath, indented: > > nt:file|<arbitrary name> > nt:resource|jcr:content > (p) jcr:encoding=... > (p) jcr:mimeType=... > (p) jcr:data=0x...... (binary content) > (p) jcr:lastModified=... > > nt:folder|<arbitrary name> > nt:file|<arbitrary name #1> > nt:resource|jcr:content > (p) jcr:encoding=... > (p) jcr:mimeType=... > (p) jcr:data=0x...... (binary content) > (p) jcr:lastModified=... > nt:file|<arbitrary name #2> > nt:resource|jcr:content > (p) jcr:encoding=... > (p) jcr:mimeType=... > (p) jcr:data=0x...... (binary content) > (p) jcr:lastModified=... > > It seems to me, what you want to version is the nt:resource, NOT the > nt:file. I am not sure what function or responsibility the nt:file node > provides, but as you know, the actual content resides in the nt:resource. > It seems reasonable that you would want to version the ACTUAL item that is > varying, not the node that contains it. You have mentioned this in your > post. Mentioned elsewhere, I cannot find it right now, David mentions > that > in his own use of the JCR, he rarely (if ever) extends nt:file, but > regularly extends nt:resource.
Unless of course you want to keep track of folder and file renames. I would be inclined to have an implicit trust in his statement on this. > Maybe naive, maybe not. So, it would seem that an extension of > nt:resource > would be preferable. > > > I have a couple additional questions to this issue of files/folders. > > 1) why the additional level of indirection with nt:file? If this is > analogous to a filesystem, the file IS the file. What is the benefit of > nt:file and nt:resource existing as separate entities? I imagine the reason is "content re-use", an nt:resource is an anonymous item that could possibly belong to an nt:file and several nt:linkedFile nodes. 2) What is involved in creating an extended nt:resource node type? Is there > a document discussing how to do this? Or would I be able to figure this > out > by inspecting the source code? I think it's nothing more than registering a new node type, like this for example: [foo:i8nResource] > nt:resource - jcr:language (STRING) 3) Because I know I will be asked, if extending nt:resource is a frequent > occurence, why is there not a "stock" version that would allow some > additional capabilities, such as extra arbitrarily named/typed properties? > In the new world of development where Enterprises want to use more "off > the > shelf" software and less custom written software, why would this not be a > part of the spec? Some folks, perhaps in our Enterprise, would view this > as > a deficiency rather than a benefit, due to the possibility of breakage as > updates occur. I have no idea, sorry. Cheers, -Tako
