Re: [Wtp-wst-dev] XPath2 - bugs + tests

[Mukul Gandhi <mukul.gandhi@xxxxxxxxxx>]

Hi all,
     I've committed the enhancements suggested by Łukasz (I corrected
fn:abs and fn:index-of implementations as per Łukasz's findings), on the
service branch which is JDK 1.4 compliant, and used by Xerces.

Thank you Łukasz.

Regards,
Mukul




From:	Jesper Steen Møller <jesper@xxxxxxxxxxxxx>
To:	"Web Standard Tools developer discussions."
            <wtp-wst-dev@xxxxxxxxxxx>
Date:	10/13/2011 02:23 AM
Subject:	Re: [Wtp-wst-dev] XPath2 - bugs + tests
Sent by:	wtp-wst-dev-bounces@xxxxxxxxxxx



Hi Łukasz,

This is great!

For purposes of tracking and especially "IP tracking", we need to track
this in Bugzilla. I'll go and create these, bug I'll need you to upload the
diffs there. If you don't have an Eclipse Bugzilla account yet, you better
get one now.

As for the cause of the "holes" in the test and implementation, two reasons
apply: 1) The tests are primarily from the W3C test suite, combined with
the specific tests for bugs found, with contriutions from different
individuals and companies. So while it covers a lot, it doesn't cover
everything. We should add your findings back into the test suite, not just
the Java version of it (I wish we had a better process for doing this)
2) The implementation started as an academic clean room implementation but
from an non-final version of the spec. When David Carver picked it up and
work started under the Eclipse WTP umbrella, the focus was on correctness
against the test suite, where we attacked it like a black box if it worked,
and only took apart the failures. So, the horrible stuff like System.exit
which obviously has NO place in a library, kept below the radar for quite a
while, but was mostly removed in the 2.0 version this year, when every file
was examined.

Mukul, would you be interested in backporting Łukasz's bugs to the 1.x
branch?

It is great to see community input to this project, and I'd love to hear
about how you use the library (unless that's confidential...)

-Jesper

2011/10/12 Łukasz Wycisk <luczus@xxxxxxxxx>
  Hello,


  We have compared CVS newest version with our local changes. Some of bugs
  has similar fixes, however there are still some which have not been fixed
  yet. Proposed fixes are in attached diffs. We tried to test our fixes
  using existing files in test case by adding methods to TestBugs.java.


  1. FnAbs: http://www.w3.org/TR/xquery-operators/#func-abs


  According to http://www.w3.org/TR/xpath20/#id-function-callsif sequence
  is expected (indicator *, +, or ?) the atomization of arguments should be
  applied. Now in case of node passed to method type error occur. However
  there is some support for atomization - FnDistinctValues was fixed
  lately. Test case:


  TestBugs:testFunctionAtomization()


  We think that in other numeric function similar errors can occur, suppose
  other tests should be added. Surprisingly there are no tests for that
  sort of situation in conformance suit (at least we haven’t found any).





  2. FnIndexOf: http://www.w3.org/TR/xquery-operators/#func-index-of


  Function should support any atomic values. It seems that there is no
  support for QNames.


  TestBugs:testFnIndexOf_onQName(),TestBugs:testFnIndexOf_onQName2()


  Second test function leads to third problem.





  3. QName._expanded which is boolean value saying if namespace was set
  (also null if default). When qname is created by function with empty
  first argument:


  http://www.w3.org/TR/xquery-operators/#func-QName


  then ._expanded is ‘true’(we think it’s correct)


  but to compare it with qname from element will always return ‘false’
  since Element.node_name() sets ._expanded to ‘false’ in case of null
  namespace (w3c.org representation of no-namespace situation is null).


  Removing if statement in constructor (QName:45) seems to solve the
  problem and do not affected other tests. However we are not sure about
  correct ._expanded parameter state. What is Your opinion?





  4. FnPlus used to have System.exit() line which caused us some trouble to
  trace. It was fixed but still there are plenty System.out statements for
  some unusual errors. Why just simply throw an exception?


  We are still investigating other differences trying to run our
  application on new library version. We will get back to You with any
  other fixes. In the meantime please let us know what do You think about
  those.


  Regards,


  Wojciech Diakowski


  and


  Łukasz Wycisk




  _______________________________________________
  wtp-wst-dev mailing list
  wtp-wst-dev@xxxxxxxxxxx
  https://dev.eclipse.org/mailman/listinfo/wtp-wst-dev

_______________________________________________
wtp-wst-dev mailing list
wtp-wst-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-wst-dev