Xsd Reader Laravel Package

Product Decisions This Supports

• Build vs. buy for SOAP/WSDL integration work. This package is the schema-parsing layer beneath wsdl-reader and the goetas SOAP client stack. If your roadmap includes consuming or generating SOAP services, this package is the "buy" component that saves you from writing an XSD parser — a spec-heavy, low-differentiation task.
• Schema-driven code generation and tooling. Because it exposes elements, complex types, attributes, and groups as traversable PHP objects, it underpins decisions about generating DTOs, fixtures, or request/response classes directly from partner-provided schemas rather than hand-coding them.
• Enterprise/partner integration feasibility. When evaluating a new partner integration (banking, logistics, government, EDI-adjacent), you can use this package to inspect and validate whether their XSDs are consumable in PHP before committing engineering time.
• Contract-first API design. Teams defining internal XML contracts can round-trip and reason about schema structure programmatically — useful for documentation generation, schema diffing across versions, and compatibility checks.
• Roadmap input: scope boundaries. The package is intentionally a reader, not a validator or generator. This clarifies where product investment stops (parsing) and where your own product must start (validation against instances, serialization, mapping to domain models).
• Vendor/lock-in and maintenance risk assessment. 61 stars and a single-maintainer profile is a real dependency decision; the MIT license and September 2025 release reduce (but don't eliminate) abandonment risk. This informs whether it's a direct dependency or a transitive one you only accept via the companion stack.

When to Consider This Package

• Choose it when: you need to introspect XSD documents as objects — resolving import/include across namespaces, walking types and groups — and you don't want to own that parser. Strong fit if you're already using goetas-webservices/wsdl-reader or the companion SOAP tooling, since it's the same author and designed to compose.
• Choose it when: your schemas are XSD 1.0-era enterprise contracts and you need extensibility hooks (the custom-schema callbacks) for the odd partner-specific quirk.
• Choose it when: the alternative is 4–6 weeks of engineering time on a spec-compliant parser that adds no product differentiation.
• Look elsewhere when: you only need to validate a specific XML document against an XSD — DOMDocument::schemaValidate() or laminas/laminas-validator is a one-line, zero-dependency answer.
• Look elsewhere when: you need XSD 1.1 features (assertions, conditional type assignment) or full spec coverage; verify against your actual schema corpus before committing, since edge-case schema constructs are the usual failure mode.
• Look elsewhere when: you need a complete, batteries-included SOAP client. This is a foundation piece, not a product; expect to assemble wsdl-reader and a transport layer around it.
• Look elsewhere when: performance-critical hot paths parse large schemas per request — cache the parsed model, or benchmark first, as object-graph construction over large schemas carries cost.
• Look elsewhere when: the team has no PHP/XSD expertise and the dependency would be unmaintained internally; a lower-level library you understand beats a higher-level one you can't debug.

How to Pitch It (Stakeholders)

Executive summary: goetas-webservices/xsd-reader is a small, MIT-licensed PHP library that turns XML Schema documents into traversable PHP objects — resolving imports and includes, tracking namespaces, and exposing types, elements, and attributes. It is the parsing foundation for SOAP/WSDL work rather than an end-user product.

Why it matters: partner and enterprise integrations frequently ship XSD contracts. Without this, we either hand-write parsers per integration or hand-code DTOs from PDFs — both slow and error-prone. This package lets us inspect, validate, and generate from schemas programmatically, shortening integration lead time and reducing defects.

What it is not: it does not validate XML instances, does not generate code out of the box, and does not provide a SOAP transport. It is a component we compose with wsdl-reader and our own mapping layer.

Risk and mitigation: low stars and a narrow maintainer base mean we should treat it as a transitive dependency of the SOAP stack, pin versions, and wrap its API behind a thin internal adapter so a future swap is cheap. MIT licensing removes legal friction.

Ask: approve it as the schema-parsing layer for the [SOAP integration] workstream, with a time-boxed spike (2–3 days) validating it against our real partner schema corpus before we commit the full roadmap.