jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: residual definition xml implementation
Date Sat, 15 Apr 2006 09:06:50 GMT
Hi,

On 4/15/06, Greg Kick <gk5885@kickstyle.net> wrote:
> your response actually outlines the reason i brought it up.  although
> the spec uses the * notation in its definitions, it pretty clearly
> states:

You are right. However, the "*" in the item definitions is rather
treated as a special marker than a real name. There are predicates
like def.getName().equals(ItemDef.ANY_NAME) and the more "correct"
def.definesResidual() in Jackrabbit sources that explicitly decide
whether a definition is residual or not, and if it is, then the name
is not used for anything else.

> further, it seems that the only reason that new QName("", "*")
> doesn't fail with an exception is that "The local part is not
> validated as a NCName as specified in Namespaces in XML" as stated in
> the javadoc for QName.

I kind of agree with you here; having an invalid QName instance feels
a bit troublesome even if it is just a marker constant. Enforcing the
use of ItemDef.definesResidual() throughout Jackrabbit sources would
allow us to hide the QName.ANY_NAME constant and allow us to use some
other way to identify residual definitions (a null name for example).

> specifically, the fact that many node type definitions aren't valid
> under nt:nodeType is worrisome.

I just doublechecked that Jackrabbit is conformant in that there is no
jcr:name property in residual item definitions under
/jcr:system/jcr:nodeTypes. You can find definesResidual() calls in
VirtualNodeTypeStateProvider guarding whether the jcr:name properties
are exposed in item definition nodes. So this is already being taken
care of.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Mime
View raw message