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. 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
