The only potential reason I see for jcr:content is if we allow a hierarchy of collections, so /a/b points to collection B and /a/b/c points to collection C.
Carsten 2013/5/6 Carsten Ziegeler <cziege...@apache.org> > 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 > -- Carsten Ziegeler cziege...@apache.org
