Any thought to releasing JDOM2 with the existing functionality and targeting XPath redesign for JDOM2.1?<br><br><div class="gmail_quote">On Fri, Jan 20, 2012 at 7:16 AM, Rolf Lear wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I agree with the debug issue. That is exactly why in the model I intend to<br>
provide I will make it possible to return the 'XPathResult<T>' and not just<br>
a List<T>.<br>
The XPathResult<T> will allow you to inspect the base XPath results in a<br>
List<Object> as well as the filter results in the List<T> format.<br>
<br>
XPath has always been a vulnerable area for type-casting. Nothing has<br>
stopped the user from coding inappropriate casts for XPath results. With<br>
JDOM2 the user will have the option of trading class-cast-exceptions for<br>
missing result conditions. If the user is anxious to keep the<br>
class-cast-exception option then they can choose to use unfiltered XPath<br>
results.<br>
<br>
In general, a user writing an XPath expression has to know ahead of time<br>
what the return types will be (including XPath 2.0 with it's plethora of<br>
atomic types). Using the Filter concept allows the user to anticipate the<br>
type of his/her choice, and not have to statically build the type in to the<br>
API.<br>
<br>
Mitigating the debug issue with a XPathResult<T> with useful methods<br>
interrogating intermediate results (and a useful toString()) is a good<br>
compromise, I think.<br>
<br>
As long as people understand that the XPath results are 'filtered' a<br>
second time then everything should be fine.<br>
<br>
Remember that the users can always elect to have unfiltered results too,<br>
but then they have to live with List<Object> results.<br>
<span class="HOEnZb"><font color="#888888"><br>
Rolf<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, 20 Jan 2012 14:57:02 +0000, Michael Kay wrote:<br>
> Thanks for the explanation.<br>
><br>
> I wonder, though, if discarding data of the wrong type is better than<br>
> throwing a ClassCastException? It's very easy in XPath, for example, to<br>
> ask for a text node when you thought you were asking for a string.<br>
> Expressions that return nothing are the hardest thing to debug as it is.<br>
><br>
> Michael Kay<br>
> Saxonica<br>
><br>
> On 20/01/2012 14:50, Rolf Lear wrote:<br>
>> No, no static type analysis.<br>
>><br>
>> JDOM has 'always' had the 'Filter' concept. You could, for example, do:<br>
>><br>
>> List comments = element.getContent(new<br>
>> ContentFilter(ContentFilter.COMMENT));<br>
>><br>
>> In order to make the above 'generic' in JDOM2, the getContent() has to<br>
>> return an appropriate type for whatever the Filter returns. I<br>
'extended'<br>
>> the Filter class to have a generic return type. Thus, it is now<br>
possible<br>
>> to:<br>
>><br>
>> List<Comment>  comments = element.getContent(Filters.comment());<br>
>><br>
>> The Filter implementations all follow the rules:<br>
>> 1. if the content to be filtered does not match the filter, then the<br>
>> content is discareded.<br>
>> 2. if the content matches the filter, then it is explicitly cast to the<br>
>> generic type of the filter.<br>
>><br>
>> What this means is that you are guaranteed that the generic type of the<br>
>> Filter results is accurate, and it is impossible to 'force' Filter<br>
>> results<br>
>> to have badly-loaded result lists.<br>
>><br>
>> Filter instances can do more than just type-checking on the input data,<br>
>> but can also do anything else to filter the content, like checking for<br>
>> particular names, etc.<br>
>><br>
>> With the XPath library, I intend to apply the same Filter concept to<br>
the<br>
>> XPath results.<br>
>><br>
>> Since the user knows the XPath expression, they will also know the<br>
>> anticipated return type. If they want to select Elements then they can<br>
>> apply an Element filter. If they want to select 'everything' then<br>
>> they can use a 'passthough' filter which 'does no filtering' (but as a<br>
>> result can only 'cast' to Object).<br>
>><br>
>> Essentially the Filter concept is a way to coerce unknown data in to a<br>
>> user defined type while ensuring the results will never generate<br>
>> class-cast, and providing an opportunity to discard what you do not<br>
want.<br>
>> It is ideal for XPath results.<br>
>><br>
>> The 'user' creates their own filter<br>
>><br>
<a href="http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/filter/Filter.html" target="_blank">http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/filter/Filter.html</a><br>
>> , or reuses one of the 'common' filters accessible in the 'Filters'<br>
class<br>
>><br>
<a href="http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/filter/Filters.html" target="_blank">http://hunterhacker.github.com/jdom/jdom2/apidocs/org/jdom2/filter/Filters.html</a><br>
>><br>
>> Most Filter implementations take a Class instance (matching the generic<br>
>> type of the Filter) as a constructor argument, and any values that<br>
match<br>
>> the filter are cast using the Class.cast() method.<br>
>><br>
>> Rolf<br>
>><br>
>><br>
>> On Fri, 20 Jan 2012 14:31:07 +0000, Michael Kay<<a href="mailto:mike@saxonica.com">mike@saxonica.com</a>><br>
>> wrote:<br>
>>>> public XPathCompiled<Object>  compile(String xpath);<br>
>>> I started introducing generics for this in Saxon 9.4 and the<br>
experience<br>
>>> wasn't wholly positive; it left a lot of cases where there were<br>
warnings<br>
>>> that needed to be ignored. That may be because I found generics to be<br>
>>> deeper and more bewildering than I expected.<br>
>>><br>
>>> It's not at all clear to me how your types such as<br>
>>> XPathCompiled<Element>  are supposed to work. Do they rely excessively<br>
>>> on<br>
>>> the ability of the XPath engine to do static type analysis of the<br>
>>> supplied expression?<br>
>>><br>
>>> Michael Kay<br>
>>> Saxonica<br>
</div></div></blockquote></div><br>