-----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-----
