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. > > 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. cheers stefan > > BR, > > Jukka Zitting
