[
https://issues.apache.org/jira/browse/XERCESJ-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468018#comment-17468018
]
J Morris commented on XERCESJ-1726:
-----------------------------------
{noformat}
Hi,
In my eagerness to simplify my previous validation files, I failed to notice
that the original actually demonstrated *errors of two distinct types*. My
recent test case only deomnstrated one of these.
The fix that you (Mukul) provided does appear to rectify that one.
I now attach a second test case that is embodies the full set of
assert/assertions in the original but also shows that some recent invesigations
that I have done. This means that it covers the other type of error that my
*tesSimplified* case did not.
The updated schma document (*test5.xsd*) in this test case includes a block of
5 highlighted assert/assertion lines, three of which are active and the other
two are commented.. One of the active asserts shows that, during validation,
the text section of the rogue lines in the XML file are being split into two
parts by a spurious *newline character*. I have no why/idea how this character
has been introduced into that line. Perhaps you have an explanation, with your
more detailed knowledge of how the validation process works.
The* two commented lines* show *the longest two regex's* that I was able to
match to this line, one for the part of the line *prior to the newline* and the
other for *the part after it*.
As ever, I would be very grateful to hear your wisdom on this issue.
Many thanks.
[^TestSecondError.zip]
{noformat}
> 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
