[ https://issues.apache.org/jira/browse/XERCESJ-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468613#comment-17468613 ]
Mukul Gandhi commented on XERCESJ-1726: --------------------------------------- I've written my own XSD 1.1 validation example, that uses your XSD idioms (to see, if Xerces has a fundamental bug as per your choice of XSD syntax). Consider following XSD document, <?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="X"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="att1" type="xs:integer" use="optional"/> <xs:assert test="matches(text(), '^abc$')"/> <xs:assert test="matches(./text(), '^abc$')"/> <xs:assert test="./text()[matches(., '^abc$')]"/> <xs:assert test="if (./text()[matches(., '^abc$')]) then @att1 else not(@att1)"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:schema> With the above XSD document, following XML instance document is valid, <?xml version="1.0"?> <X att1="1">abc</X> Whereas, following XML instance document is invalid (all <assert>s return false result), <?xml version="1.0"?> <X att1="1">abcg</X> I'm of the conclusion that, Xerces is very much compliant. > 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) --------------------------------------------------------------------- To unsubscribe, e-mail: j-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: j-dev-h...@xerces.apache.org