[PR] Let the configured number limit reach schema compilation [poi-xmlbeans]

pjfanning opened a new pull request, #100:
URL: https://github.com/apache/poi-xmlbeans/pull/100

   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`
   
   ```java
   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](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]