[RT] More generic datamodel for JcrCollectionProvider & JCR v2.0

[David Nuescheler <da...@day.com>]

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/

Re: [RT] More generic datamodel for JcrCollectionProvider & JCR v2.0

[James M Snell <ja...@gmail.com>]

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
> 
> [1] http://jcp.org/aboutJava/communityprocess/pr/jsr283/
> 

Re: [RT] More generic datamodel for JcrCollectionProvider & JCR v2.0

[Davanum Srinivas <da...@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

2 cents from the peanut gallery...Makes perfect sense to me!

- -- dims

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
|
| [1] http://jcp.org/aboutJava/communityprocess/pr/jsr283/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFHoI4TgNg6eWEDv1kRAn7oAJ92Vh+72swAvHzzC2zvcVTKC/+/4ACfeQ+w
3/HZwMTAWlF3GZr9/O8IYlg=
=z8yk
-----END PGP SIGNATURE-----