jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Clarifying: Support for properties and child nodes with the same name
Date Wed, 30 Oct 2013 10:43:54 GMT
On Tue, Oct 29, 2013 at 1:46 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> On Mon, Oct 28, 2013 at 6:54 PM, Tobias Bocanegra <tripod@apache.org> 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?


[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

View raw message