jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Clarifying: Support for properties and child nodes with the same name
Date Wed, 30 Oct 2013 18:25:23 GMT

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.


Jukka Zitting

View raw message