Hi, Is it important that I get the particular svn revision that you quote below, in order to get the fixed version of Xerces-J?
At the URL: https://svn.apache.org/repos/asf/xerces/java/branches/xml-schema-1.1-dev/ I now see revision 1896867. If important, how do I backtrack to the revision you quote? Best regards, John. > On 08 January 2022 at 08:06 "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:all-tabpanel > ] > > Mukul Gandhi resolved XERCESJ-1726. > ----------------------------------- > Resolution: Fixed > > committed fix for this jira issue, with svn revision 1896825. now with > the examples posted on this jira issue, XML document source types sax and > stream work fine as well. > > > > 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 > > Assignee: Mukul Gandhi > > Priority: Major > > Labels: test > > Attachments: TestSecondError.zip, TestSimplified.zip, 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.20.1#820001) >
