[
https://issues.apache.org/jira/browse/XERCESJ-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi updated XERCESJ-1726:
----------------------------------
Description:
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).
was:
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).
> 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.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: j-dev-h...@xerces.apache.org
