Hi Patrick, First of all, thanks a lot for your response. I completely agree that 3rd party applications may well be the most important driver for explicit structure.
> My bottom-line: Structure is expensive and in many cases it is > entirely unnecessary to explicitly declare structure to the underlying > storage. I'm finding this to be true as I use Jackrabbit more; however... > There is an implicit contract about structure that your application > inherently uses. Let's say I store the modification date of a blog > post in a "lastModified" property. My App will automatically know to > read the modification date from that same property again, there is > really no neod to declare that explicitly. But I thought the goal of a "generalized" CMS solution, like JSR170, was to enable 3rd-party apps the ability, after viewing/looking up/receivig some meta-data, the ability to read the store itself w/o having source-code access to the business rules in your app.
It is true that expressing structure in nodetypes is one of the very important requirements for a general Content Repository API like JCR, and that's precisely why nodetypes are a part of the JCR spec. I would never argue that we should remove them from the spec. However, the design goals of "my application" certainly may be different from the design goals of the JCR specification. In many cases I don't know yet if another application that is going to access my content. Sometimes, I even don't want an other application access my "private" content. To be honest, sometimes I don't even know where my applications are going when I start with the development, so I try to defer the cost of structure to the point in time and the pieces where it becomes necessary. I fully agree that once you know that other 3rd party applications are accessing your content the implicit contract inside your application is not sufficient anymore. And that's the point in time when you want to incur the cost to explicitly structure and describe the parts of the content that you would like to be accessed by other apps. Nodetypes certainly are one of the tools that a content repository gives you to do that. But...
Storing specific types is supposed to be the way that 3rd party apps make sure they're using the nodes in your store correctly, if I'm understanding the generalization goals of JSR170 at all.
... the nodetyping system is just one way (a very important one) of expressing structure. It is important to also think of for example the hierarchy as a means to transport information about the structure. An example like ... /content/myblog/posts/iphone_shipping ... transports inherent information. If I would access the content repository with a generic browser I would know where to find stuff, and somehow (and maybe that's just me drinking too much of my own kool-aid) I would simply try to add a new "post" to the blog by simply adding a new node to "posts" at the top of the list ;) Does that make sense at all? It is also important to keep in mind that the contract expressed by nodetypes may not be sufficient for an application or a developer to understand how to use the content. Much like an ERD or a DDL may not bear all the semantic constraints. I think additional explanatory documentation may be necessary anyway. Since I see a lot of cases where explicit structure in nodetypes is very important, 3rd party applications probably being the most important driver. Maybe, I should re-name this rule to something like "Structure on Demand". Thoughts? regards, david
