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. regards, Lukas Kahwe Smith [email protected]
signature.asc
Description: Message signed with OpenPGP using GPGMail
