On Tue, Oct 29, 2013 at 1:46 AM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Mon, Oct 28, 2013 at 6:54 PM, Tobias Bocanegra <[email protected]> wrote: >> I would rather keep the support for same name properties and nodes in >> order to ensure backward compatibility for existing repositories. > > I tend to agree. There don't seem to be too many benefits to keeping > the current design, and the backwards compatibility aspect might well > be a real problem for existing deployments. > >> Are there any other areas where the item name ambiguity is not >> properly handled, because we assume no same name property and node >> names? e.g. in permission evaluation, search, etc? > > I think the most prominent case is the MicroKernel JSON model. But it > should be quite straightforward to adjust the JSON format, for example > by putting all child nodes within an extra ":children" object.
the JSON representation of the repository as exposed by the MicroKernel API naturally mirrors the content structure and is IMO intuitive. i don't think we should introduce artificial intermediary objects like ":children" since it breaks the 1:1 mapping of repository content and leads to awkward client code. WRT same named node and property (SNNP): 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? cheers stefan [1] http://www.day.com/specs/jcr/2.0/5_Reading.html#5.1.8%20Node%20and%20Property%20with%20Same%20Name > > There are some other cases, like the simple URL and JSON mappings in > the oak-http draft, that would need to be adjusted, but I don't think > any of these would require too much effort. > > AFAICT the core functionality in oak-core and oak-jcr is mostly > unaffected by this, given the structure of the Tree and NodeState APIs > that (reflecting the JCR API) make a clear distinction between > properties and child nodes. > > BR, > > Jukka Zitting
