well, i'm glad that jackrabbit behaves correctly internally. the
reason i brought this up originally was because NodeTypeWriter
creates documents with the *. i had wanted to create an xml schema
to check that a node definition was valid (i needed xml, not cnd).
so, i figured that i would do it by using xslt to transform the
definitions outputted by NodeTypeWriter into a schema, but since *
isn't a valid NCName it would fail. so the question is, if the *
isn't used internally, why is it reintroduced in the xml output?
can this be considered a bug or just a design choice i don't agree
with? :-) i'm even willing to do the work to remove it and submit a
diff, but i don't want to go through all of the effort if there is a
reason it is being used here...
greg kick
http://kickstyle.net/
On Apr 15, 2006, at 2:06 AM, Jukka Zitting wrote:
Hi,
On 4/15/06, Greg Kick <[EMAIL PROTECTED]> 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/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development
