Product Decisions This Supports
- Build vs. buy for XML ingestion: this is the "adopt" option when you need schema (XSD) validation at the boundary of an integration. It's a thin, MIT-licensed wrapper over PHP's built-in libxml, so the build-vs-buy math favors adopting unless you have unusual requirements.
- Roadmap scoping for partner/regulatory integrations: any roadmap item that means "we accept XML from a third party" — e-invoicing (CFDI, UBL), ISO 20022 payments, government filings, EDI-adjacent formats — needs a validation gate. This package is the enforcement mechanism behind that gate.
- Definition of done for data-exchange features: lets you commit to "invalid documents are rejected with actionable per-line errors" instead of generic failures, which is a materially different support burden.
- Two-layer validation architecture: use XSD validation here for structural correctness, and reserve Schematron/XSLT or application rules for business semantics. This package helps you draw that line explicitly rather than conflating the two.
- Test strategy: run generated XML fixtures through it in CI against published XSDs to catch regressions when a partner or regulator ships a schema version bump.
- Support triage: structured validation errors let support distinguish "the partner sent bad data" from "our parser is broken" — a recurring, expensive ambiguity in B2B integrations.
- Onboarding decisions: a schema-driven validator makes adding partner N+1 cheaper, because onboarding becomes "drop in the XSD and wire the gate" rather than new bespoke parsing code.
When to Consider This Package
Adopt when:
- You're on PHP/Laravel and XML is a first-class integration format.
- Authoritative XSDs exist and are versioned by the counterparty or regulator.
- You want clean, structured error reporting rather than raw libxml warnings bleeding into logs.
- You want a small, permissively licensed dependency with negligible surface area.
Look elsewhere when:
- Your stack isn't PHP, or you'd rather validate in a separate service.
- Requirements include XSD 1.1 (assertions, conditional type assignment) — libxml and therefore this package are XSD 1.0.
- You need Schematron business rules, XSLT transformation, or JSON Schema — different tools, not gaps this fills.
- Documents are very large and memory-constrained: libxml loads the document rather than streaming it.
- You require vendor-backed support or an SLA. At 15 stars, zero dependents, and effectively a single maintainer, treat this as a small open-source bet.
- You're already standardized on Symfony Validator or a comparable abstraction and want one validation interface across formats.
Diligence before adopting: pin the version, wrap it behind your own DocumentValidator interface to avoid lock-in, and add integration tests around your actual schemas — the low community size is the main risk, and the MIT license plus thin wrapper are what keep that risk cheap to unwind.
How to Pitch It (Stakeholders)
For executives: This is a low-cost, MIT-licensed library that hardens the front door of our XML integrations. It rejects malformed or non-compliant documents before they reach billing, ledger, or fulfillment logic — reducing manual reconciliation, partner escalations, and the compliance exposure that comes from silently accepting bad data. Because it's small and permissively licensed, the cost of switching away later is low.
For engineering: It removes the boilerplate around libxml's schemaValidate and returns structured errors (message, line, column) instead of warnings you have to suppress and parse. It's not a framework — it sits behind an interface and is straightforward to unit test.
For product and compliance: It turns "we validate against the published schema" into a verifiable, testable claim — useful in audits, partner contracts, and RFP responses.
Known caveats to state up front: XSD 1.0 only, single maintainer, small community. Mitigation is architectural, not wishful: isolate it behind an internal interface and let the integration tests be the contract.