Xml Laravel Package

Product Decisions This Supports

• Legacy integration roadmap: Whether to build an in-house abstraction over PHP's native SoapClient/DOMDocument for our SOAP connectors (banking, ERP, shipping, government/tax APIs, payment gateways), or adopt a maintained low-level XML layer instead.
• Build vs. buy (make vs. adopt): This package is a primitive, not a full client. It lets us standardize how we read, validate, and construct SOAP envelopes and namespaces rather than hand-rolling DOMDocument code in every connector. The decision it informs is "adopt a shared XML/SOAP envelope layer" vs. "write our own helper class."
• Architecture of the integration layer: Supports a decision to isolate SOAP concerns behind an internal interface (e.g., a SoapGateway contract) so the underlying library can be swapped. php-soap/xml is one implementation detail beneath that boundary.
• Ecosystem alignment: If we adopt the broader php-soap/* suite (client, WSDL tooling, engines), php-soap/xml is the common substrate; pulling it in is a coherence decision, not a standalone one.
• Use cases unlocked: Consuming or producing SOAP envelopes in Laravel jobs/services, signing/WSSE-adjacent workflows at the XML layer, fixtures and assertions in tests for SOAP payloads, and normalizing namespace-heavy documents that PHP's native tooling handles clumsily.
• Risk posture: At ~10 stars, this is a low-adoption, small-surface dependency. It supports a decision to pin, vendor, or fork rather than treat it as a strategic platform bet.
• Not a decision it supports: It does not replace a full SOAP client, WSDL code generation, or a schema validator. Don't let it anchor a "we now have SOAP covered" narrative.

When to Consider This Package

Consider it when:

• You have a hard requirement to speak SOAP — a partner, bank, ERP, or government API exposes only SOAP/WSDL, and a REST wrapper is not on offer.
• You are already in, or moving toward, the php-soap/* ecosystem and want the same envelope/namespace abstraction across connectors.
• You need object-oriented, testable XML handling for SOAP payloads — assertions on generated envelopes in PHPUnit, or safe construction of namespace-qualified elements — and would otherwise write and maintain that helper yourself.
• The team wants a thin, MIT-licensed, composable primitive with a small API surface that is cheap to vendor or fork if upstream stalls.
• You value recent release activity as a maintenance signal; the published cadence suggests the maintainers are still shipping.

Look elsewhere when:

• The integration target is REST/JSON — this is the wrong tool entirely.
• You need a full client (transport, WSDL parsing, HTTP layer, fault handling). Use php-soap/client or the native SoapClient; this package is a layer underneath that.
• You need WSDL-to-PHP code generation — that's a different package (php-soap/wsdl / generator territory).
• Your org has a dependency-approval bar tied to adoption metrics. Ten stars will not clear a security/governance review on popularity alone; you'll need to argue on code size, license, maintainer activity, and forkability — or accept the internal maintenance cost.
• You need schema validation, WSSE signing, or MTOM/attachments out of the box; verify coverage explicitly before committing.
• A well-supported alternative already exists in your stack (e.g., Laminas SOAP, Symfony Serializer's XML encoder). Don't add a second XML abstraction for its own sake.
• The team is not PHP-8-comfortable or not on modern Laravel/PHP — check version constraints against your runtime before assuming fit.

How to Pitch It (Stakeholders)

For executives (30 seconds): "We have integrations — banking, ERP, a couple of partner APIs — that only speak SOAP, an older XML-based protocol. Right now each connector reinvents the same fragile XML plumbing. php-soap/xml is a small, MIT-licensed, actively maintained PHP library that gives us one clean, tested way to build and inspect those SOAP messages. Cost is effectively zero, it's a narrow piece of plumbing rather than a platform commitment, and because it's MIT we can vendor or fork it if the project ever stalls. The real value is risk reduction: less bespoke XML code, fewer integration incidents, faster delivery on legacy connectors. It does not replace a full SOAP client — it sits underneath one — so this is a targeted, low-stakes adoption, not a bet-the-roadmap decision."

For engineering leads:

• Small surface, low lock-in: It's an XML wrapper, not a framework. Isolate it behind our own gateway interface and it becomes a one-file swap.
• Ecosystem coherence: It's the shared substrate under php-soap/client, so adopting it now avoids a later refactor if we standardize on that suite.
• Testability: Object-oriented envelopes make payload assertions in unit tests straightforward — a genuine improvement over string-concatenated XML or raw DOMDocument calls scattered through services.
• Mitigations for the low star count: pin the version, add a lockfile, run it through our dependency scanner, and note that MIT + small codebase makes an internal fork a weekend task, not a quarter.
• Explicit non-goals: transport, WSDL generation, WSSE, and schema validation are out of scope for this package — budget those separately if the integration needs them.