[
https://issues.apache.org/jira/browse/XERCESJ-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469866#comment-17469866
]
Mukul Gandhi edited comment on XERCESJ-1726 at 1/7/22, 4:29 AM:
----------------------------------------------------------------
about your question, related to <assert test="if (./text()[matches($value, ... )
<xs:assert> is an XSD element (just like other XSD elements, for example
<xs:element>, <xs:complexType> and so on). When <xs:assert> is evaluated, as
part of XSD validation episode (<assert> is a validation constraint as part of
a complexType), the XSD validator evaluates <xs:assert>'s XPath expression to
determine true or false result (<xs:assert> evaluation returns only a true or a
false result. A true result here means that, the element validated by
complexType is valid, otherwise is invalid). <assert>'s XPath expression
evaluation has access to a specific XPath dynamic and static context (all this
is done, by an XSD validator's XPath engine at run-time) which are populated as
defined by the XPath 2.0 spec. I think, the XPath expression's dynamic context
has a context node reference, relative to which the XPath expression is
evaluated.
For your example, <assert test="if (./text()[matches($value, ... ), the .
(before /text()) refers to the context node and $value has an XSD typed value
($value is a sequence of atomic items. for example, xs:string* is a run-time
type annotation for $value).
was (Author: mukul_gandhi):
about your question, related to <assert test="if (./text()[matches($value, ... )
<xs:assert> is an XSD element (just like other XSD elements, for example
<xs:element>, <xs:complexType> and so on). When <xs:assert> is evaluated, as
part of XSD validation episode (<assert> is a validation constraint as part of
a complexType), the XSD validator evaluates <xs:assert>'s XPath expression to
determine true or false result (<xs:assert> evaluation returns only a true or a
false result). <assert>'s XPath expression evaluation has access to a specific
XPath dynamic and static context (all this is done, by an XSD validator's XPath
engine at run-time) which are populated as defined by the XPath 2.0 spec. I
think, the XPath's dynamic context has a context node reference, relative to
which the XPath expression is evaluated.
For your example, <assert test="if (./text()[matches($value, ... ), the .
(before /text()) refers to the context node and $value has an XSD typed value
($value is a sequence of atomic items. for example, xs:string* is a run-time
type annotation for $value).
> 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: [email protected]
For additional commands, e-mail: [email protected]
