Hi Lukas, On Mon, Oct 28, 2013 at 3:58 PM, Lukas Kahwe Smith <[email protected]> wrote: > > On Oct 28, 2013, at 23:54 , Tobias Bocanegra <[email protected]> wrote: > >> Hi, >> >> On Mon, Oct 28, 2013 at 2:48 PM, Jukka Zitting <[email protected]> >> wrote: >>> Hi, >>> >>> On Mon, Oct 28, 2013 at 3:12 PM, Tobias Bocanegra <[email protected]> wrote: >>>> I don't know anymore where I heard/read this, but I had the >>>> assumption, that oak will no longer support properties and child nodes >>>> with the same name. >>> >>> Yes, you're correct. However, we don't really actively enforce this >>> limitation and the data structures used by our all our backends >>> actually do make it possible for a node and a property to have the >>> same name, so it might well be that it's in practice possible to >>> create such content structures. The original idea as implemented by >>> the older H2 MK was to use just a single JSON-like map for both nodes >>> and properties, but that approach is troublesome given the need to >>> support flat hierarchies. >>> >>> I think we should fix that in one way or another: either explicitly >>> check for such name collisions at the storage level or alternatively >>> revert the earlier decision and allow a property and a child node to >>> have the same name. >> >> I would rather keep the support for same name properties and nodes in >> order to ensure backward compatibility for existing repositories. It >> would also keep the support for importing XML documents where >> attribute and element names can have equal values. >> >> 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 guess one issue with supporting this right now is that it can cause > "broken" JSON that needs a custom parser to deal with. So imho if this > feature is kept, it might be necessary to come up with a better JSON > encoding, which in turn would then break the existing JSON API.
Where can it cause broken JSON? In the Apache Sling JSON serialization? Yes, but this is already a "problem" for Sling on Jackrabbit 2.x. Which also uses the not quite correct child-node ordering assumption for JSON. Regards, Toby
