Xsd2Php Runtime Laravel Package

Product Decisions This Supports

• Schema-first XML integrations: Enables a workflow where XSDs are treated as contracts and converted into generated PHP DTOs, making XML/SOAP integration work more predictable and reviewable.
• Build vs. buy for serialization plumbing: Avoids spending engineering time hand-writing XML hydration/serialization logic for schema-generated models. The runtime supplies base types, interfaces, and JMS Serializer handlers needed by generated classes.
• Production/runtime separation: Supports keeping code-generation tooling out of production deployments. The generator is a build-time/dev dependency; this package is the small runtime dependency shipped with generated code.
• Roadmap input for integration-heavy products: If the roadmap includes SOAP APIs, XML feeds, partner integrations, legacy enterprise systems, or schema-driven data exchange, this package can reduce time-to-integration and lower XML-mapping risk.
• Use-case fit: Strongest for PHP services that must consume or expose XML defined by XSDs and want generated object models rather than ad hoc arrays/DOM manipulation.
• Maintenance decision: The package is narrowly scoped, MIT-licensed, and Composer-installable. The PM decision is less “adopt a platform” and more “standardize the runtime companion for generated XML models” where xsd2php is already the chosen generation approach.

When to Consider This Package

Consider it when:

• Your team has decided to use xsd2php to generate PHP classes from XSD schemas.
• Generated classes will be used at runtime and require the base types/interfaces and JMS Serializer handlers provided by this runtime.
• You need to (de)serialize XML into PHP objects in a maintainable, schema-driven way.
• You want to keep code-generation dependencies out of production while still shipping the required runtime support.
• You are integrating with SOAP services, enterprise XML APIs, or partner systems where XSD contracts are authoritative.
• You are comfortable adding JMS Serializer-related runtime dependencies and can manage generated code as part of your build pipeline.

Look elsewhere when:

• You are not using xsd2php-generated classes; this package is a runtime companion, not a standalone XML mapper.
• Your integration is JSON/OpenAPI-first rather than XML/XSD-first.
• Your XML needs are simple enough for SimpleXML/DOMDocument or a lightweight custom parser.
• You need a full SOAP client framework, WSDL tooling, or higher-level integration platform; evaluate phpro/soap-client or similar instead.
• You require a large, actively maintained ecosystem with strong community support. This package has a narrow scope and modest adoption, so dependency and maintenance risk should be assessed.
• You cannot tolerate generated code in your repository/build process, or you need dynamic schema handling without a code-generation step.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed runtime library that supports a schema-first approach to XML integrations. It lets us generate PHP object models from XSD contracts and use them in production without shipping code-generation tooling. The business value is faster, more reliable integration with SOAP/XML partner systems and less custom serialization code to maintain. The main risk is its narrow scope and limited community size, so it should be adopted only where we are already standardizing on xsd2php.

For engineering: Adopt this as the runtime dependency for xsd2php-generated classes. It provides the base types, interfaces, and JMS Serializer handlers that generated models expect, keeping the generator out of production. It is not a full XML/SOAP framework; it assumes xsd2php is the generation tool and JMS Serializer is acceptable in the runtime stack. Treat generated code and schema versions as build artifacts, pin versions, and add integration tests around XML round-tripping. If we are not using xsd2php, or if the integration is JSON-first or simple XML, this package is unnecessary.