Hi Mukul, Hope you are well.
Am I correct in thinking that no-one on the Xerces developer side has picked up my error report and is investigating it? Is there anything that I can do to make that more likely to happen? Failing that, the I guess that it's down to me to look into the Java code. My initial ideas on this were to use the Eclipse Development/Debug environment and attempt to set breakpoint(s) around the "unexpected" errror events. However, this requires source code for all (most) of the Java classes. In the way I was running the tests, I was using ".jar" files to provide the definition of most classes. It has so far proved impossible to insert a breakpoint into a class coming from a ".jar" file. To work round this restriction, my idea was to utilize the source code either from the "Xerces with source" download or from the selected JDK version. I have used the jar executable to list the contents of the Xerces ".jar" files and I am busy trying to map namespaced class names to their source. Once this mapping is complete, I plan to reference the relevant source files directly from Eclipse and then set the necessary breakpoints. Potential snags are with ".jar" entries with no corresponding source fies (e.g. org.eclipse.wst.xml.xpath2.processor_1.2.0.jar). Does this approach sound reasonable to you? Many thanks, John. > On 06 September 2020 at 06:14 "Mukul Gandhi (Jira)" > <xerces-j-...@xml.apache.org mailto:xerces-j-...@xml.apache.org > wrote: > > > > [ > https://issues.apache.org/jira/browse/XERCESJ-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191197#comment-17191197 > > https://issues.apache.org/jira/browse/XERCESJ-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191197#comment-17191197 > ] > > Mukul Gandhi edited comment on XERCESJ-1726 at 9/6/20, 5:13 AM: > ---------------------------------------------------------------- > > I do feel that, John's test cases point to unexpected behavior with > Xerces-J, and may be a possible bug. > > @John: Xerces-J is open source. If you're inclined to look at its java > code, and suggest to us that what could be a possible fix and perhaps write > and share a patch as well, that would be great and speed the incorporation of > fix for this issue within Xerces-J. > > > was (Author: mukul_gandhi): > I do feel that, John's test cases point to unexpected behavior with > Xerces-J, and may be a possible bug. > > @John: Xerces-J is open source. If you're inclined to look at its java > code, and suggest to us what could be a possible fix and perhaps write and > share a patch as well, that would be great and speed the incorporation of fix > for this issue within Xerces-J. > > > > Possible Bug: Xerces 2.12.1 for XML Validation with XSD 1.1 > Schema under Java > > > > ----------------------------------------------------------------------------- > > > > > > > > Key: XERCESJ-1726 > > URL: https://issues.apache.org/jira/browse/XERCESJ-1726 > > Project: Xerces2-J > > Issue Type: Bug > > Components: Samples > > Affects Versions: 2.12.1 > > Environment: Windows 7 > > Java 1.8.0_261 > > Xerces-J 2.12.1 > > Reporter: J Morris > > Priority: Major > > Labels: test > > Attachments: testX.zip, test_cases_ mukul.zip > > > > > > > > Original Estimate: 72h > > Remaining Estimate: 72h > > > > > > > > I have recently been trying to validate the XML file *test1.xml* > with a schema *test.xsd* containing *assert*/*assertion* constructs, using > the sample program *jaxp.SourceValidator*. > > Unexpectedly, the result was several reported errors in what > > appeared to be syntactically correct and valid XML lines (*test1.xml*: 9 > > errors). > > After significant experimentation, it appeared that these errors > > were occurring at line numbers which the validation found troublesome. > > Inserting an extra line at one of the troublesome line numbers made the > > previously erroneous line (now *not* appearing at a troublesome line > > number) pass validation. On the other hand, the newly inserted line > > (occupying the troublesome line number) would fail validation. > > I tentatively interpreted this as meaning that *the validation > > errors were not real* and began to try to develop a test-case, as similar > > as possible to *test1.xml*, but which passed validation. The result was > > *test2.xml*, which was generated from *test1.xml* by inserting XML comment > > lines at each of the troublesome line numbers, thereby displacing the > > previously erroneous lines to non-trooublesome line numbers. Since XML > > comment lines do not require validation, this file passed validation for me > > (*test2.xml*: 0 errors). > > I then contacted Mukul GANDHI and he re-ran my validations *but > > came to a different result*. He saw errors in both XML files (*test1.xml*: > > 9 errors; *test2.xml*: 18 errors). Despite our joint efforts to achieve > > convergence between our respective validation runs, we have not so far > > succeeded. > > Mukul did point out a couple of things: > > 1) The way that I was using the "matches" function in the *assert* > > constructs. His experience suggested that this was unreliable. However, I > > was not certain whether this would have led to the type of behaviour that I > > was seeing (apparent troublesome line numbers). > > 2) He found that certain characters (probably the two accented > > French characters) in my XML files were not supported in the default XML > > encoding scheme, UTF-8. However, for me, no errors were reported for those > > by the validation program *jaxp.SourceValidator*. > > I would be very gratefull foe some help in getting to the bottom of > > this (both the original behaviour and the discrepancies with Mukul's > > validation runs). > > > > > > > -- > This message was sent by Atlassian Jira > (v8.3.4#803005) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: j-dev-unsubscr...@xerces.apache.org > mailto:j-dev-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-dev-h...@xerces.apache.org > mailto:j-dev-h...@xerces.apache.org >
