Saxon

It's "char 173" rather than "column 173". It's the best we can do, because we don't have full information from the XML parser. The basic location information provided by SAX only gives us the line and column corresponding to the ">" at the end of the element's start tag; and the value that we see for attributes has been subjected to XML's attribute whitespace normalization. So the best we can do is report a character offset within the pattern.

Thanks MK.

I understand, we have quite a lot of patches in Xerces in order to compute the precise location for each attribute name and value.

Unfortunately as XPath expressions increase in complexity, splitting them on multiple lines becomes quite common and locating precisely on what line the XPath is broken would have been valuable to the end user.

Yes, it would be great to have more precise line/column information, but without a customized XML parser I can't see how to achieve that.

Perhaps if oXygen has better information, we could define some kind of interface that allows the information to be made available to Saxon?

Or we could try and structure the location information in an XPathException for XPath static errors more precisely, so that it includes (a) the line/column of the containing element, as defined by the SAX SourceLocator, (b) the attribute name, and (c) the line/column relative to the attribute value as supplied to Saxon - this would only be useful if XML attribute value normalization is suppressed.

Second choice looks quite interesting. So you could have a custom XPathException implementation which besides line and column reporting (which would remain unchanged) would report the attribute name and a relative offset in the attribute value where the problem is encountered.

Indeed the main problem remains the fact that Xerces will normalize attribute values when the SAX callback is received.

The XNI level in Xerces still has the non-normalized value: org.apache.xerces.xni.XMLAttributes.getNonNormalizedValue(int).

When the SAX content handler receives the startElement() callback the "Attributes" interface you receive is actually the concrete object "org.apache.xerces.parsers.AbstractSAXParser.AttributesProxy" which contains inside it the "protected XMLAttributes fAttributes;" field.

So possibly you could use Java reflection to get this field and ask it for the unaltered attribute value. And if it fails, fallback to the normalized value. But I'm not sure that you want to tie Saxon to a specific parser implementation.

OK, I've got the denormalization part working. If the stylesheet parser is an instance of Apache Xerces, I stick an adapter into the pipeline which modifies the Attributes object to substitute the pre-normalization value for the normalized value. The adapter uses reflection as you suggested.

And we could do the same thing when validating XSLT stylesheets, provide a source for the XSL with a custom XMLReader which actually provides non-normalized values. As long as Saxon does not rely on certain attribute values being already normalized by the Xerces processor. Also this would only apply to the parser used for the XSLT stylesheet, the parser for the XML would behave as it previously did.

There might be a problem with entity references. The not normalized value might have the entity references not expanded which would be a problem.

Also there may be very rare cases in which the XPath expression has custom entity references other than the simple amp, lt, gt and character reference ones (maybe somebody added a DOCTYPE to the XLST stylesheet defining them). So in cases in which the non-normalized values contains unknown entity references, there would be need to fallback to the normalized value.

That remark about newlines and tabs in xpath literals is quite interesting. We would need to know/test exactly how Xerces normalizes spaces in attribute values. For example if the value has two consecutive simple spaces (%20), does it report only one after the normalization? Or does it just convert tabs and new lines to simple spaces? Probably Xerces also compacts consecutive spaces. If it would not do that, there would be no problem with the reported location relative to the beginning of the attribute value.

For a stylesheet I think we can usually assume that there is no DTD, or if there is one, it does not contain element/attribute declarations. Therefore the attributes will be CDATA attributes, which means that attribute-value normalization will convert newline and tab characters to x20, but will not collapse multiple space characters into single space characters.

Then the offset relative to the start of the attribute value should be quite accurate.

Test boolean-082 fails with these changes. It contains the LRE

           @<td style="color: #336699; font-weight:

bold">HCFA Jcodes:

           <td>@

(lines wrapped as shown, almost certainly unintentionally)

and the effect of the change is that the generated HTML replicates the newline instead of substituting a space, causing a failure to be reported by the test suite.

Hi Michael,

I think you chose the right approach. After you release 9.7 we'll try to see if we can benefit of these changes in Oxygen XML Editor for showing more precise validation errors.

Regards,

Radu

Thanks Michael.