hi,
On Apr 15, 2006, at 3:05 PM, Jukka Zitting wrote:
Hi,
On 4/15/06, Greg Kick <[EMAIL PROTECTED]> wrote:
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?
The reasons I outlined before apply to the node type xml format as
well: 1) the JCR spec uses "*" as the name of residual definitions,
and 2) the internal ItemDef.ANY_NAME matches "*" in string format.
I think that that is actually the crux right there. When you say
that the JCR spec uses "*" as the name, that's true, but only if it's
the string representation in cases like ItemDefinition.getName().
This seems to me to say since residual definitions have no name
property (of type NAME), return "*". And this has obvious advantages
over returning null or something. So with that, we're on the same
page. And further, I hadn't realized at first glance that
jackrabbit's QName wasn't the standard java implementation, so that
allows for some latitude even though QName.checkFormat
(ItemDef.ANY_NAME.getLocalName()) still fails.
I just think that there needs to be a clearer differentiation between
when the name is a NAME (from the spec) and when it is the String (in
java) representation of that NAME. I've spend so long debating this
mostly because it seems that hacks like the QName misnomer and your
xsl catch will continue to propagate throughout code for both
jackrabbit and client apps if it isn't consistent. Even right now,
the name shows up in the NodeTypeWriter output as a *, but not in
the xml document or system views. And we've identified that behavior
throughout this discussion, but does it make sense that the
marshaling mechanisms should give different results??? or results of
different types (xs:string vs. xs:QName)???
<rant>We're now trying to juggle two different representations of a
single concept as a java String, java QName, xml string and xml QName
in an implementation that doesn't really make a clear distinction
when it is going to be using which!</rant>
Can you use something like the following in your XSLT to cover case:
<xsl:template match="[EMAIL PROTECTED]'*']">
<!-- handle residual definition -->
</xsl:template>
<xsl:template match="propertyDefinition">
<!-- handle named definition -->
</xsl:template>
+ the same for childNodeDefinition.
And that's why your stylesheet isn't an ideal solution. Where I
would have been able to transform the definition into a schema that
would check that the name property is an xs:QName (after being
escaped per 6.4.3), this defers handling that property until it is
already part of a specific propertyDefinition or childNodeDefinition
element. (instead of validating a general nt:NodeType, i'm
validating each specific type) However, since the document view
gives a more type-safe, intuitive version, I think that I'll opt to
use that instead. Actually, as an aside, why is it a separate
representation anyway?
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...
The main reason for keeping the current internal implementation (using
ItemDef.ANY_NAME) over an alternative is that the current design is
proven to work and there is no compelling enough reason to change it.
As for the node type XML format, I wouldn't change that even if the
alternative design (not having a name attribute in residual definition
elements) was considered better or more correct. The current format
works and changing it would break backwards compatibility of the
JackrabbitNodeTypeManager.registerNodeTypes methods.
As a final thought, I come into this as someone who hasn't coded any
portion of the project, but has read the spec many times. So, while
I have a pretty solid understanding, I lack the pragmatic
perspective. But, I really would hate to see it all get more
confusing as the project progresses just because opting against some
clarification now was protecting the backwards compatibility of a
project just out of the incubator.
Anyway, I rest my case and thanks for the discussion regardless.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development
greg kick
http://kickstyle.net/
