Xml Wrangler Laravel Package

Product Decisions This Supports

• Build vs. buy for XML plumbing. The recurring failure mode on integration roadmaps is that every team writes "a small XML helper," and every helper is differently wrong. A tiny, MIT-licensed, single-purpose dependency turns that into one decision made once. Cheapest possible way to close the question.
• Estimate compression on integration-heavy backlogs. Any roadmap touching XML-speaking partners — payment gateways, carriers and logistics, ERP/SAP exports, banking/ACH, regulatory filings, marketplace feeds — carries an undocumented multi-week buffer for parsing and generation. Standardizing shrinks each of those line items simultaneously, which changes what fits in a quarter without changing headcount.
• Integration viability and sales commitments. "Read this partner feed" or "generate this payload" becomes CRUD-shaped work rather than a research project. That directly affects whether a customer-requested integration is commercially viable at the quoted price and how confidently sales can commit to a delivery date.
• Roadmap sequencing for legacy/SOAP modernization. New Laravel services get a first-class XML read/write path, which removes the "we need a translation layer first" blocker that quietly defers legacy retirement quarter after quarter. This is what turns a modernization theme into dated milestones.
• Architecture standard, not just a library. Naming one opinionated, testable pattern for all XML connectors is a platform decision. Once named, it can be enforced in code review, which is where consistency actually gets created.
• Defect and compliance exposure. Where serialized output is contractual — filings, clearing messages, partner specs checked structurally — uniform generation reduces the "it serialized differently this time" class of incident. That is risk reduction with a paper trail, not merely velocity.
• Reversibility as a decision advantage. Narrow surface, MIT license, stable 1.x line, wrapper rather than framework. You can decide this in an afternoon instead of running a full architecture review cycle, and the cost of being wrong is roughly a day.
• Feature-level go/no-go on customer requests. When an enterprise account asks for an XML-based integration, this package is the difference between "we'll scope it" and "yes, that's in the next sprint." Useful ammunition in renewal and expansion conversations.

When to Consider This Package

Adopt when:

• You are on modern PHP (8.3+) and already use Saloon, or are prepared to. This is the strongest signal by far. XML arriving inside Saloon response objects and being readable in a few fluent lines is the actual product. Outside that context it degrades to "a generic XML wrapper" and the case weakens materially.
• Multiple endpoints or partners speak XML, or the trend line says that number grows. At one or two, the dependency overhead can exceed the boilerplate saved — though the second integration is usually where it pays for itself.
• You must write XML, not just read it. Attribute handling, namespace mapping, CDATA, and standalone declarations are exactly where hand-rolled code degrades fastest and where defects hide.
• You need XPath-style querying and namespace mapping without making the whole team fluent in DOM, XPath, and SimpleXMLElement quirks. The typed query API with generics is the genuine differentiator versus "just use SimpleXML."
• Consistency and testability matter — contract-bound output, regulated formats, partner specs that must match structurally across environments.
• You want bounded blast radius. Pin the version, wrap it in a thin internal adapter, keep real partner fixtures in contract tests, and record the exit path so "replace it in a day" stays true.

Look elsewhere or hold when:

• XML is a single one-off integration. Use DOMDocument / SimpleXMLElement and move on. Do not spend the decision budget.
• XSD schema validation is the primary requirement. This reads and writes; it does not validate. Pair with a dedicated validator — and say so explicitly, or someone will assume coverage that isn't there.
• You need XSLT, complex XML-to-XML mapping, or rich document modeling. Different tool category entirely.
• The XML is hostile or non-standard — irregular nesting, malformed partner output, encoding chaos. Defensive normalization still has to sit in front of any parser; this package does not absorb that work.
• Very large batch jobs. Treat LazyQuery and streaming claims as unproven for your documents until spiked against real payloads and memory ceilings.
• Adoption footprint is a gating criterion for you. Note the public dependents count is effectively zero and the star count is in the low hundreds. That is normal for a young, single-maintainer utility, but it means no community firehose and no crowd-sourced edge-case coverage. Your own contract tests are the safety net.
• Governance-heavy procurement. A few-hundred-star, effectively single-maintainer package will fail some security or vendor-review processes. Surface that on day one rather than after the pilot.

How to Pitch It (Stakeholders)

For executives:

"We pay a recurring tax on XML. Every partner integration that speaks XML — payment gateways, carriers, ERP exports, regulatory filings — gets quoted with a multi-week buffer because engineers hand-roll parsing and generation each time. Those hand-rolled parsers are where a disproportionate share of integration bugs surface, and they surface late, against real partner payloads.

XML Wrangler is a small, MIT-licensed open-source PHP package that replaces that ad-hoc work with a standard, tested approach that fits the stack we already run. It is not a new platform and not a vendor commitment: no infrastructure, no license cost, no lock-in. It is a library we could remove in a day.

The business case is estimate compression and defect reduction. Work that currently carries a two-to-three week XML allowance should land in days, and the class of bugs that only appear against live partner data should shrink because the parsing logic is uniform and testable. Across several XML integrations a year that returns real engineering capacity, speeds time-to-revenue on partner-dependent features, and lowers exposure where output format is contractual.

Proposal: pilot on the next XML integration already on the roadmap. Success criteria: delivery time versus comparable past integrations, defect count in the XML layer, and engineer confidence at the end. If it holds, standardize across integration teams. Spend is essentially zero, plus about a day of engineering to pilot. If the pilot disappoints, we walk away having lost a day."

For engineering leads:

"This is the boring, correct answer to 'how do we do XML' in a Saloon-based codebase. It is a thin ergonomics layer — an XPath-flavored query API with generics for typed results, attribute and namespace handling, and a chainable writer for generating payloads — sitting over a maintained underlying XML library (veewee/xml). It is not a framework and does not pretend to be.

What it replaces: SimpleXMLElement fiddling, DOM traversal boilerplate, regex 'parsing', and per-integration snowflake code. What you get is one pattern for every XML connector: read in a few lines, query fluently, map into DTOs, generate requests from arrays or DTOs. It has tracked PHP 8.3, 8.4, and 8.5 promptly across releases, and it is maintained by the same author as Saloon, so the maintenance posture is live rather than abandoned and the API conventions will feel familiar to anyone already writing connectors.

Be honest about the limits. It reads and writes; it does not validate against XSD — pair it with a validator where that matters. Streaming and LazyQuery should be treated as unproven for our documents until spiked. Adoption footprint is thin: effectively no public dependents, low hundreds of stars, one maintainer. That is fine for a utility this narrow, but it means we are the ones proving it out, not the community.

Guardrails, which are cheap: pin the version, put a thin internal facade in front of it, keep real partner fixtures in contract tests, and write down the exit path. With those in place this is a low-risk dependency that pays for itself on the second XML integration. Without them we are just adopting a dependency we don't understand."