 | 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: |
3 messages in org.apache.abdera.devRe: [RT] More generic datamodel for J...| From | Sent On | Attachments |
|---|---|---|
| David Nuescheler | Jan 30, 2008 6:43 am | |
| Davanum Srinivas | Jan 30, 2008 6:47 am | |
| James M Snell | Jan 30, 2008 7:36 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: [RT] More generic datamodel for JcrCollectionProvider & JCR v2.0 | Actions... |
|---|---|---|
| From: | James M Snell (jasn...@gmail.com) | |
| Date: | Jan 30, 2008 7:36:26 am | |
| List: | org.apache.abdera.dev | |
Although my knowledge of the JCR is limited, generally speaking, the less abdera-specific invention we need, the better. If there are existing types that can be leveraged and mapped to corresponding Atom types, then we should be using them.
- James
David Nuescheler wrote:
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