Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of uncled@day.com designates
 62.192.10.254 as permitted sender)
Message-ID: <1b0d43d00801300644i7e331f60v32487121611ce2a2@mail.gmail.com>
Date: Wed, 30 Jan 2008 15:44:00 +0100
From: "David Nuescheler" <david@day.com>
Sender: uncled@day.com
To: abdera-dev@incubator.apache.org
Subject: [RT] More generic datamodel for JcrCollectionProvider & JCR v2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Guys,

this is probably mostly a question for Dan.

Currently the JcrCollectionProvider uses an Abdera namespace
and an Abdera specific nodetype. Which basically means that
Abdera uses JCR to persist its content, but would not
expose existing arbitrary "content" to Atom. As far as I can tell,
this has never been a design goal of the JcrCollectionProvider, so
there is absolutely nothing wrong with that...

When looking at the information set of Atom and comparing it to
some of the additional "mixin types" specified in the public review
document of JSR-283 [1] where we specify the following...

4.7.23.8 mix:title
[mix:title] mixin
  - jcr:title (string)
  - jcr:description (string)

4.7.23.9 mix:created
[mix:created] mixin
  - jcr:created (date)
  - jcr:createdBy (string)

4.7.23.10 mix:lastModified
[mix:lastModified] mixin
  - jcr:lastModified (date)
  - jcr:lastModifiedBy (string)

...there are similarities that lead me to believe that we
could use either these mixin nodetypes or at least just the same
property names.

In turn this would mean that we don't really need an Abdera specific nodetype
or an Abdera specific namespace at least for these properties, but abdera
could read from any node that exposes the above mixins.

I think this would allow to map a simple Atom feed just off of arbitrary content
living in a JSR-283 compliant repository. In my mind I could see something
like the following "Atom Element" to "JCR Property" mapping:

atom:title -> jcr:title
atom:updated -> jcr:lastModified
atom:author -> jcr:createdBy
atom:id -> jcr:uuid
etc...

Does that make sense?

In my mind this would allow content repository applications that are not
specifically Abdera aware (like our blog: http://dev.day.com) to
simply expose an Atom interface by just running Abdera on the
same existing workspace.

Maybe this is beyond the purpose of the current implementation...
Of course JSR-283 is not final yet, but I just wanted to check
if anybody else thought that this more generic approach could
make sense.

regards,
david

[1] http://jcp.org/aboutJava/communityprocess/pr/jsr283/