jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Re: DM Rule #1: Data First, Structure Later. Maybe.
Date Mon, 09 Jul 2007 08:27:28 GMT
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

Mime
View raw message