jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Clarifying: Support for properties and child nodes with the same name
Date Wed, 30 Oct 2013 18:57:35 GMT
hi 

just a quick update on the status quo in response to our discussion
during our weekly oak meeting related to OAK-1126:

if my tests are correct SNNP actually does work in OAK and we could
theoretically just flip the descriptor to return true. then the descriptor
would match the implementation (patch attached to the issue).

kind regards
angela

On 10/30/13 7:25 PM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>Hi,
>
>On Wed, Oct 30, 2013 at 6:43 AM, Stefan Guggisberg
><stefan.guggisberg@gmail.com> wrote:
>> SNNP was introduced with JSR 283, mainly due to pressure from vendors
>>with
>> legacy systems. we (day) were opposed since SNNP renders JCR paths
>> ambiguous (IMO a serious problem). BTW SNNP are an optional repository
>> feature [1].
>>
>> we shouldn't make the same mistake twice. and as for the aforementioned
>> "import xml" use case: remember that the "import xml" feature brought us
>> JCR namespaces and SNS, both widely considered major flaws in the JCR
>>API?
>
>Right, but it doesn't necessarily follow that SNNP is also a major flaw.
>
>In fact most content structures and access patterns I've seen make a
>big distinction between properties and child nodes, so it makes sense
>to treat them separately on the storage layer (as discussed, all our
>backends do that). From that perspective having a shared namespace for
>properties and child nodes goes against the grain, as it forces a
>backend to either use a data structure that's not optimal for common
>access patterns or to do extra work to prevent separate data
>structures from overlapping.
>
>BR,
>
>Jukka Zitting


Mime
View raw message