Xmlschemavalidator Laravel Package

Technical Evaluation

Architecture fit. eclipxe/xmlschemavalidator is a narrowly scoped, dependency-light wrapper over PHP's native DOMDocument::schemaValidate, exposing an object-oriented API for validating an XML document against an XSD, plus structured access to libxml errors. For a Laravel application it is a library, not a framework concern — it touches no Laravel contracts, ships no service provider, and makes no assumptions about HTTP, storage, or config. That is a positive: it slots in as an infrastructure adapter behind an interface we own, and can be swapped for a different validator (external service, CLI xmllint, or a heavier Java/Saxon pipeline) without touching domain code. It is a pure validation primitive; any business-rule enforcement (amounts, tax logic, cross-field constraints) is explicitly out of scope and would require Schematron or hand-written rules.

Integration feasibility. High. Composer install, ext-dom and ext-libxml — both present in every standard PHP build and in Laravel Sail/Forge/Vapor-era runtimes unless stripped. No Laravel version constraint, no PHP framework coupling, MIT license, so legal review is trivial. The main engineering work is not adopting the library but governing the schemas: sourcing XSDs, resolving xsd:import/xsd:include, pinning schema versions, and deciding where schema files live (repo vs. object storage vs. a bundled vendor package).

Technical risk.

• Correctness risk is in the schemas, not the code. XSD 1.0 cannot express most business rules; teams routinely mistake "schema-valid" for "correct". Expect to pair this with Schematron or explicit domain validation.
• Failure-mode opacity. libxml errors are terse and often reference line/column in the schema rather than the document, or collapse multiple causes. Budget for an error-normalization layer and a mapping to user-facing messages.
• Schema resolution. Relative xsd:include/import plus remote schemaLocation values are a real hazard: they can trigger outbound HTTP (SSRF-adjacent, latency, non-determinism) or silently fail to load a schema. Pin schemas to the local filesystem, disable network access via libxml flags, and assert the validator's return value rather than assuming success.
• Memory profile. DOM loads the whole document; large payloads (multi-MB invoice batches, EDI dumps) will pressure workers.
• Statefulness under long-running workers. The validator instance accumulates errors; reusing a single instance across requests in Octane/Swoole risks leaking prior errors into a later result. Treat it as request-scoped.
• Adoption signal. 15 stars, 0 dependents in this dataset, effectively a single-maintainer project. The blast radius is small (a few hundred lines wrapping a PHP built-in), so forkability is high — but do not expect a rapid upstream response to an edge-case bug.

Key questions.

1. Which document types and which versions of each schema must we accept, and who owns the schema artifacts?
2. Is structure-only validation sufficient, or do we need business rules (implying Schematron)?
3. What is the maximum document size and required p95 validation latency?
4. Do we validate inbound (untrusted, hostile input) or outbound (our own generated XML)? The threat model differs sharply.
5. What is the acceptable behavior on schema-load failure — fail-closed (reject) or fail-open with alerting?
6. Are we contractually obliged to return spec-quality error messages to partners/customers?
7. Does the deployment target guarantee ext-dom/ext-libxml, and are we running Octane?

Integration Approach

Stack fit. The package sits naturally at the boundary layer: an XmlSchemaValidator adapter bound to a SchemaValidator interface in a service provider, consumed by a FormRequest rule, a queued job, or an artisan command. It has no opinion on transport, so it composes cleanly with Laravel's HTTP validation, queue, filesystem, and event systems. Keep it out of controllers and models.

Migration path.

1. Spike (1–2 days). Validate a representative corpus — a handful of known-good documents, a handful of known-bad — and confirm error output is usable. This is the decisive gate; if error messages are unusable, the cost shifts to the normalization layer.
2. Vendor the schemas. Store XSDs in resources/schemas/{type}/{version}/, committed, reviewed, and versioned alongside code. Never resolve schemas from the network in production.
3. Thin adapter. One class implementing our interface: validate(string $xml, string $schemaKey): ValidationResult returning {valid: bool, errors: Error[]}. Normalize libxml errors into a stable DTO here so the upstream library's shape never leaks into call sites.
4. Laravel validation rule. A XmlSchema rule for FormRequest usage where documents arrive over HTTP and are small. Return human-readable messages mapped from error codes.
5. Async path. For batch or large-document flows, move validation into a queued job with an explicit size ceiling and timeout; surface results via events rather than return values.
6. Observability. Log schema key, schema version, byte size, duration, and first-error code on every validation. Emit a metric for invalid-rate per document type — a sudden spike means an upstream partner changed something, and that alert is worth more than the validator itself.

Compatibility. Confirm PHP floor against the app's minimum (the library tracks modern PHP, so legacy 7.x apps may be excluded). Verify behavior across PHP minor versions for libxml error formats, which differ subtly. If running Octane, resolve the validator per-request, never as a singleton.

Sequencing. Schemas first (they gate everything), adapter second, HTTP rule third, async pipeline last. Do not start with the async pipeline — most teams discover their real requirements from the synchronous path.

Operational Impact

Maintenance. Low code churn — the underlying PHP API is stable, so upstream releases are infrequent and small. The real maintenance burden is schema lifecycle: new document versions, deprecations, and partner-specific variants. Assign an explicit owner for schema artifacts; unowned schemas rot fastest and fail loudest.

Support. No commercial backing and a small maintainer base; issues are handled through GitHub, best-effort. Mitigate with the interface boundary — if upstream stalls, replacing the adapter with a direct DOMDocument::schemaValidate call is a day's work, and forking is realistic given the code volume. Do not accept a hard dependency on a library-specific API from more than one call site.

Scaling. Validation is CPU-bound and roughly linear in document size with a DOM memory multiplier. For typical webhook/API payloads (tens to low hundreds of KB) it is negligible. For batches, parallelize across queue workers and cap concurrency; track memory per worker to find the threshold where a large document OOMs a process rather than returning an error. Set a hard byte ceiling at the edge (request validation / upload limits) so oversized documents are rejected before they reach libxml.

Failure modes to design for.

• Missing ext-dom after a base-image change — validate at boot/healthcheck, fail loudly.
• Schema file missing or moved — validation throws or returns false with a schema-side error; distinguish "document invalid" from "schema unavailable" in the result type, and fail closed.
• Silent schema load failure producing a false pass — always assert the boolean and inspect errors.
• Malformed XML (not well-formed) vs. schema-invalid — different handling and different user messaging.
• Entity expansion / remote entity fetch — set libxml flags to disable network access and external entities; treat all inbound XML as hostile.
• Error-message truncation or localization gaps surfacing to end users.
• Octane/singleton reuse carrying stale errors between requests.

Ramp-up. The API itself is an afternoon — build, validate, read errors. The genuine ramp is XSD literacy: namespaces, import vs. include, schema versions, and interpreting libxml diagnostics. Budget one engineer for two to three weeks to reach production confidence including the schema governance and error-mapping work; assume one to two days if you only count wiring the library in. The 15-star footprint means documentation and Stack Overflow answers are thin, so plan on reading the source and the libxml docs rather than searching for prior art.