3 Commits

Author	SHA1	Message	Date
Mihaela Mihaljevic	380160cc2b	refactor(validation): decompose XSD instance validation into composable rules ... The two monolithic XSD content/identity rules only satisfied the OpenAPIKit validation idiom at the wrong granularity: no per-constraint removability, no isolable failing/near-miss tests. Split them into 32 named rules, each finding tagged at its origin and cached per XSDContext so the walk still runs once per document (the #101 decision against duplicating XSD's recursive type resolution still holds). Wired the streaming path's ID/IDREF and identity checks through the same framework instead of calling the validators imperatively, and added the unwrapAndLookup combinator the rule already named as required. Also includes the mandated repo-wide swiftformat/swiftlint pass.	2026-07-12 14:12:17 +02:00
Mihaela Mihaljevic	ead838f83c	perf(parsing): dispatch element-content markup on the byte after '<' (#276) ... The element-content markup dispatch ran up to five literal string comparisons (</, <!--, <![CDATA[, <?, <!DOCTYPE) before the start-tag branch won, a per-element cost the parse profile indicted as Reader.matchesBytes. Branch instead on the single byte after '<' on the byte fast path: '/' end tag, '?' processing instruction, '!' a declaration, otherwise a start tag. The Character path keeps the equivalent matches()-based dispatch for a streaming source or spliced entity text, and a '<!' that matches none of comment/CDATA/DOCTYPE still falls through to the start-tag scanner with the same expectedName error. Measured parse ~9.5x -> ~9.0x slower than libxml2 on the 20k-item corpus; the byte and Character paths are held identical by ParserPathDifferentialTests over its adversarial corpus, and the Xalan, W3C, and RELAX NG suites stay green. No spec behavior changed.	2026-06-24 19:25:10 +02:00
Mihaela Mihaljevic	2f8ca9b289	perf(parsing): byte-level scanning fast paths halve parse time vs libxml2 (#275) ... Keep the reader on its byte fast path through dispatch and name/attribute scanning so plain-ASCII documents avoid the per-Character String machinery (String.Iterator.next, string comparison, small-string materialization, bridge-object ARC) that a profile indicted as the parse bottleneck. The root cause was that a single buffered lookahead Character defeated every existing byte path, each of which requires an empty buffer, and the content, markup, and attribute dispatch each peeked a Character before scanning. Add a non-buffering peekByte for dispatch, a byte-mode skipSpace, an all-ASCII takeASCIIName, and an attributeRunBytes bulk scanner (with the 3.3.3 whitespace-to-space transform, deferring any carriage return to the Character path so CRLF is not double-counted). Detect a text run's closing '<' via peekByte instead of buffering it, which had cascaded the next element's whole dispatch and name scan onto the slow path. Skip reference decoding for ampersand-free text. The Character path remains the exact fallback for a streaming source, spliced entity text, and any non-ASCII byte; the two paths share scanContentMarkup so they cannot diverge. Measured parse 20.1x -> 9.5x slower than libxml2 on the 20k-item generated corpus, roughly a 53 percent wall-clock reduction. A differential oracle pins the byte and Character paths to identical event streams and error marks over an adversarial corpus, alongside boundary tests. Verified against the full local suite, the Apache Xalan XSLT gold-output corpus, the W3C XML conformance corpora, the RELAX NG spec suite, and the WASM build. No spec behavior changed.	2026-06-24 18:46:58 +02:00