Dear oxygen-user@oxygenxml.com,

I have a question about the error messages <oXygen/> reports when validating a Relax NG rule that types an item as xsd:integer. My test XML is:

<?xml version="1.0" encoding="UTF-8"?>

<?xml-model href="n.rnc" type="application/relax-ng-compact-syntax"?>

<stuff>1</stuff>

and my test Relax NG is:

start = stuff

stuff = element stuff { xsd:integer {minInclusive = "1" maxInclusive = "1"} }

As I expected, both "1" and "01" pass validation. Initially I (erroneously) expected "1.0" to pass because I thought validation cared only about the value space, and not the lexical space, and it didn't because I had misunderstood how integer was defined. Section 3.3.13 integer of https://www.w3.org/TR/xmlschema-2/ plainly says "disallowing the trailing decimal point", a limitation of the lexical space that automatically disallows the trailing zero.

I am, though, puzzled by the error message that <oXygen/> displays for "1.0", which reads:

character content of element "stuff" invalid; must be a decimal number without any significant digits after the decimal point

I think that the wording of the error message suggests that "1." should pass, since the message seems to implies that the decimal point is fine, and the mistake was putting a zero after it. Yet validating "1." raises:

character content of element "stuff" invalid; must be an integer

This is consistent with the spec, as cited above, but also, I think, misleading because the value of "1.0" is an integer, and the prohibited trailing decimal point is about the lexical representation of the value. The error message doesn't distinguish value space from lexical space, although it could.

Am I alone in thinking that these two error messages could be clearer because the error in both cases is the same: the lexical space of xsd:integer does not permit a decimal point? Neither of these messages fingers the decimal point as the invalid part of the content.

Sincerely,

David