Ok, found it in the bug; I think "sling:members" is fine and I don't see any need for jcr:content. It doesn't provide any additional value, so let's just go with sling:members
Carsten 2013/5/6 Carsten Ziegeler <cziege...@apache.org> > Sorry to ask, but what is jcr:content for? > > Regards > Carsten > > > 2013/5/6 Amit.. Gupta. <amitg...@adobe.com> > > I am in favour of keeping both jcr:content and sling:members, it might >> look additional today. But this will ensure that we have enough flexibility >> to evolve in future. >> >> If this looks fine to everyone, I can work on a patch.. >> >> Thanks, >> -Amit >> >> -----Original Message----- >> From: Felix Meschberger [mailto:fmesc...@adobe.com] >> Sent: 06 May 2013 13:13 >> To: dev@sling.apache.org >> Subject: Re: Please vote for SLING-2853 >> >> Hi >> >> I have just committed the latest patch. Thanks for that so far. >> >> I am sure the discussion and fine-tuning will continue. So I invite to >> continue such discussions and create follow-up issues for >> implementation/fixes/etc. >> >> As for the last comment by AlexK: Yes, the jcr:content/sling:members >> child node may sound like an additional redirection. On the other hand it >> will help keeing the tree structure structurized -- Once we have some data >> stored out there it will probably become harder and harder to change the >> structure later. So much like API I like to get data structures right as >> early as possible. >> >> Regards >> Felix >> >> Am 06.05.2013 um 09:11 schrieb Felix Meschberger: >> >> > Hi >> > >> > Am 06.05.2013 um 08:54 schrieb Bertrand Delacretaz: >> > >> >> On Sun, May 5, 2013 at 11:40 AM, Carsten Ziegeler < >> cziege...@apache.org> wrote: >> >>> ...One thing we imho should discuss is whether this should be using >> >>> the api package, like o.a.s.api.resource.collection; We could leave >> >>> it in the separate bundle as is right now, and once we consider it >> >>> stable, move the package to the official API package.... >> >> >> >> That would work but there's some potential for confusion if we do >> >> that, I prefer a separate o.a.s.collections package as now. >> > >> > Yes, the current proposal is o.a.s.resource.collections which sounds >> > good IMHO >> > >> > Regards >> > Felix >> >> > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org