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

Reply via email to