Let the configured number limit reach schema compilation

[pjfanning]

Started as the StscTranslator.buildBigInt item — parse the numeric facets of a schema under the configured limit rather than the hardcoded default. Tracing it showed buildBigInt was never even reached, and two paths on the way to it threw instead of reporting.

1. buildBigInt used the default limit — StscTranslator:1515

totalDigits, maxLength and the other numeric facets are numbers in a schema document, and schemas are input too — in scomp, xsd2inst and downloaded imports, not always trusted ones. StscState.setOptions already receives the XmlOptions and keeps a handful of fields, so _maxNumberOfCharsForNumbers joins them.

2. Schema validation dropped the options — SchemaTypeSystemCompiler:228

XmlOptions validateOptions = new XmlOptions().setErrorListener(errorWatcher);
if (options != null && options.isValidateTreatLaxAsSkip()) { ... }

A fresh XmlOptions carrying the error listener and one flag, so the limit never reached the validation pass that runs over the schema documents. This is what made 1 unreachable: validation failed on the facet before compilation looked at it.

3. validate() threw instead of reporting — Validator:1113

Not schema-specific. validateAtomicType parsed the decimal outside the ValidationContext:

XmlInteger 2000-digit .validate() -> IllegalArgumentException: Number has more than 1024 characters
XmlDecimal 2000-digit .validate() -> IllegalArgumentException: Number has more than 1024 characters
XmlDouble  2000-digit .validate() -> returned false, 1 error

xs:double behaves correctly because JavaDoubleHolderEx.validateLexical takes the limit and reports through the context. The decimal branch never got the same treatment: the lexical check preceding it validates characters but not length, so nothing is reported and the parse throws. validate() is the method that says what is wrong with a document — a number past the limit is bad input like any other and now comes back as an error.

4. buildBigInt threw while materialising the facet — StscTranslator:1512

value.getStringValue() sat outside the method's own try, and it can fail in its own right: it triggers the lazy set_text on the facet's typed value under the schema document's limit. A schema loaded with a lower limit than the number it declares threw XmlValueOutOfRangeException out of compileXsd. Moved inside.

Note on raising the limit

The limit is fixed when a document is loaded, so a schema has to be parsed with the raised options as well as compiled with them. Passing raised options only to compileXsd leaves the schema document itself on the default, and the facet is rejected when its text is materialised — now as a reported error rather than a thrown one. The tooling paths already pass one XmlOptions to both.

Tests

testValidateReportsAnOverLongNumber covers 3 for xs:integer and xs:decimal. testSchemaCompileHonoursLimit covers 1 and 2 — a schema whose maxLength facet is 2000 digits compiles under maxChars(4096) and is reported invalid under the default.

Full suite: 3090 tests, 0 failures.

🤖 Generated with Claude Code