Project

Profile

Help

Bug #6085

closed

Incomplete path in error messages in validation report

Added by Tim Weisenberger over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Diagnostics
Sprint/Milestone:
-
Start date:
2023-06-20
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
11, 12, trunk
Fix Committed on Branch:
11, 12, trunk
Fixed in Maintenance Release:
Platforms:
.NET, Java

Description

When using the validation with XSD in Saxon EE, in the case of erroneous attributes only the erroneous attribute is reported in the validation report, but not its associated node in the path. With this path, however, no distinct access via XPath to the erroneous node is possible. As an example for an erroneous path in the error nodes I have created the example below.

<?xml version="1.0" encoding="UTF-8"?>
<PIM>
    <category id="c-1" title="Products"/>
    <category id="c-2" title="Sub-Category"/>
    <category id="c-3" title=""/>
    <category id="c-4" title=""/>
</PIM>
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="PIM">
        <xs:complexType>
            <xs:sequence>
                <xs:choice maxOccurs="unbounded">
                    <xs:element name="category" type="categoryType"/>
                </xs:choice>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

    <xs:complexType name="categoryType">
        <xs:attribute name="id" type="xs:ID" use="required"/>
        <xs:attribute name="title" use="required">
            <xs:simpleType>
                <xs:restriction base="xs:string">
                    <xs:minLength value="1"/>
                </xs:restriction>
            </xs:simpleType>
        </xs:attribute>
    </xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<validation-report xmlns="http://saxon.sf.net/ns/validation"
                    system-id="file:/example.xml">
   <error line="5"
           column="34"
           path="/Q{}PIM[1]/@title"
           xsd-part="2"
           constraint="cvc-complex-type.3">Value "" contravenes the minLength facet "1" of the type of attribute title</error>
   <error line="6"
           column="34"
           path="/Q{}PIM[1]/@title"
           xsd-part="2"
           constraint="cvc-complex-type.3">Value "" contravenes the minLength facet "1" of the type of attribute title</error>
   <meta-data>
      <validator name="SAXON-EE" version="12.2"/>
      <results errors="2" warnings="0"/>
      <schema file="/example.xsd"
               xsd-version="1.1"/>
      <run at="2023-06-20T06:25:13.022229341Z"/>
   </meta-data>
</validation-report>

For a distinct access to the erroneous node, I would expect the following path:

/Q{}PIM[1]/Q{}category[3]/@title

However, only the following path is provided:

/Q{}PIM[1]/@title
Actions #1

Updated by Michael Kay over 1 year ago

Thanks for reporting it. I've reproduced the problem and I have added a test case (TestValidator.testAttributePathInReport). I can see what's wrong, and I can see how to fix it, but it's a case where I need to be very careful that the fix doesn't have unwanted side effects, especially as we have rather few regression tests for the exact content of error messages.

Actions #2

Updated by Michael Kay over 1 year ago

The problem is that the path to the current node is maintained by a PathMaintainer on the validation pipeline, and this is calling startElement() on the next stage in the pipeline BEFORE it adds the element name to the stack. Historically this is because the call on startElement validated that the element name was permitted here; then the path was updated; then the attributes were validated. But in recent releases the call on startElement passes across all the attributes for validation.

The cleanest solution seems to be to update the path BEFORE calling startElement(), and then take steps to ensure that on paths other than attribute failure, the final element name on the path is not repeated. I'm not fond of unnecessarily changes to code on paths that are working, but it seems to be the only way.

Actions #3

Updated by Michael Kay over 1 year ago

I've tested the change with a few more validation errors and in all cases tested, I'm now getting a correct path.

Actions #4

Updated by Michael Kay over 1 year ago

  • Category set to Diagnostics
  • Status changed from New to Resolved
  • Assignee set to Michael Kay
  • Applies to branch 11, trunk added
  • Fix Committed on Branch 11, 12, trunk added
  • Platforms .NET, Java added
Actions #5

Updated by Tim Weisenberger over 1 year ago

Hello Michael Kay,

thank you very much for fixing the bug so quickly. Is there already a schedule when this bugfix will be available for use with Saxon EE 12 Java?

Thank you

Tim Weisenberger

Actions #6

Updated by O'Neil Delpratt over 1 year ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 12.3 added

Bug fix applied in the Saxon 12.3 maintenance release.

Actions #7

Updated by O'Neil Delpratt over 1 year ago

  • Status changed from Closed to Resolved

Leaving this bug issue as resolved until resolved against Saxon 11.

Actions #8

Updated by Debbie Lockett over 1 year ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 11.6 added

Bug fix applied in the Saxon 11.6 maintenance release.

Please register to edit this issue

Also available in: Atom PDF