On 2013-10-31 12:59, Stefan Guggisberg wrote:
On Wed, Oct 30, 2013 at 7:25 PM, Jukka Zitting <[email protected]> wrote:
Hi,
On Wed, Oct 30, 2013 at 6:43 AM, Stefan Guggisberg
<[email protected]> 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.
SNNP renders JCR paths ambiguous, which IMO *is* a major flaw in the JCR spec.
SNNP addressed a serious flaw in JCR 1.0, as many (most?) content
repositories indeed treat properties and child nodes as distinct things.
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.
i OTOH have seen a lot of JSON recently ;). SNNP breaks
the intuitive 1:1 JSON representation of repository content.
that's what bothers me most.
The 1:1 representation already falls apart due to child node ordering.
Best regards, Julian
