jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Kick <gk5...@kickstyle.net>
Subject Re: residual definition xml implementation
Date Sun, 16 Apr 2006 08:51:53 GMT

On Apr 15, 2006, at 3:05 PM, Jukka Zitting wrote:

> Hi,
> On 4/15/06, Greg Kick <gk5885@kickstyle.net> 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="propertyDefinition[@name='*']">
>         <!-- 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/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development

greg kick

View raw message