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