Mapping the data mapping world
A complex and overlooked field in data integration
Imagine landing in Amsterdam after a long flight from the United States. Your laptop battery is nearly dead. You dig the charger out of your bag — and the plug doesn’t fit the wall socket.
Nothing is actually broken. The electricity on both sides is still electricity. The voltage can usually be converted. The only problem is that the two sides speak a different physical language. So you reach for a travel adapter. It doesn’t change what electricity is — it simply translates one interface into another.
Data mapping works the same way. Two systems can both describe the same customer, invoice, or order, and still disagree completely on how to represent it. One application stores an address as a single address object; another splits it into street, zipcode, and city. One system speaks XML, another JSON, a third CSV. Somewhere in between, something has to act as the travel adapter.
What is data mapping?
That something is called data mapping — also known as data transformation, or, in Gregor Hohpe and Bobby Woolf’s Enterprise Integration Patterns, the Message Translator. Unlike a physical travel adapter, though, translating business data is rarely just a matter of changing the shape of the plug.
At its core, data mapping defines how information in one system corresponds to information in another. It’s not only about format — XML to JSON, say — but about preserving meaning as data crosses the boundary. An OrderID in one system may need to become a PurchaseNumber in another; a single FullName field might need to be split into FirstName and LastName. Get the format conversion right and the mapping can still be wrong.
That distinction is the whole game. Converting XML into JSON is the easy part — modern libraries do that in milliseconds. The hard part is understanding the business meaning underneath: which fields actually correspond, which values need translating, and which information can safely be dropped. Figuring that out usually takes far longer than writing the transformation itself.
Mapping isn’t always necessary — if every party agrees to a shared standard like EDI or HL7, there’s nothing to translate. But in practice, almost every system defines its own format, which makes data mapping arguably the single most common integration pattern in existence.
Curiously, most integration frameworks — Apache Camel, Spring Integration — don’t offer direct support for it. They offload the job to specialized languages and tools instead. Given how genuinely hard the problem is — different formats, different field names, different structures, all at once — it’s easy to see why.
The field of data mapping doesn’t have an universal solution, but many languages and techniques. This blog is an overview of that, including some of my opinions I gathered over time:
Part 1 — The Three Stages of Every Mapping
Every mapping, however it’s eventually built, goes through the same three phases.
1. Understanding the problem (design time). This is the requirements and analysis phase, and it’s usually the hardest one, precisely because it always involves two sides. Someone has to define what needs mapping, agree on formats, gather real examples, share schemas, and work out the functional correspondence field by field.
The bottleneck here is rarely processing time — it’s lead time. Different departments, or entirely different organizations, need to compare notes, and in practice that happens far less through prepared workshops than through scattered email threads and video calls where half the right people aren’t even in the room. Integration and data-mapping expertise is often scarce, which is exactly why larger organizations bring in a dedicated integration specialist to run this analysis and write the mapping.
2. Building the mapping (development time). Only once the requirements are settled does anyone start writing the actual transformation. Broadly, there are three ways to do it:
- Coding — a general-purpose language (Java, C#) or a domain-specific transformation language (XSLT, JOLT, and the like)
- Templating — merging a static template with dynamic data
- Visual tooling — drag-and-drop mappers that generate code underneath
Each of these deserves its own detailed look — that’s Part 2.
3. Running the mapping (runtime). Once deployed, an entirely different set of concerns takes over: throughput on large documents, streaming versus loading everything into memory, and latency under load. A mapping that reads beautifully can still fall over in production if it wasn’t written with these constraints in mind.
Part 2 — Languages and Tools
In the initial design phase, there aren’t many tools available besides just talking and writing the design down in a document or spreadsheet. AI will probably transform this phase in the coming years. Fortunately, for the build phase, several programming languages and tools already exist, which are discussed in this section.
Coding
Coding: general-purpose languages
Writing a mapping in Java or C# usually follows the same pattern: serialize the source document into an object, map that object to another object (by hand, or with a tool like MapStruct), then deserialize it into the target format. Programmers often reach for this instinctively — it’s familiar — but it tends to be the wrong choice. The code obscures the actual mapping logic, adds resource-intensive steps, and is tied to one language and platform.
A few general-purpose languages stand out as exceptions worth knowing about:
But even with very good support for data formats, it often takes specialized languages to really tackle the complexity of data transformation.
Coding: domain-specific languages
DSLs are usually the better fit, because they come with built-in ways to query the source, manipulate data, and validate the output. They split into two families:
Get Raymond Meester’s stories in your inbox
Join Medium for free to get updates from this writer.
1.Format-specific
Format-agnostic
Apache Camel’s own Simple language deserves a mention too — it’s built specifically to combine query languages like XPath, JSONPath, and jq to pull from multiple sources at once, rather than to define a full mapping on its own.
Templating
A templating language merges a static template with dynamic data to produce output — often text like an email or generated code, though some can take structured data as both input and output. Freemarker is probably the strongest templating option for data mapping, capable of turning complex nested structures into XML, JSON, or CSV. Mustache is worth knowing for lightweight, cross-language, logic-free mapping.
XSLT gets lumped in with templating engines fairly often — Camel itself lists it as one — and it’s easy to see why: its syntax is built around the <xsl:template> tag, and it's frequently used to turn raw XML into readable HTML. But calling XSLT a templating language undersells it badly. XSLT doesn't operate on text streams at all; it's a tree-to-tree transformer, where a template is a declarative pattern-matching rule, not a fill-in-the-blanks document. As of version 3.0, it's a fully Turing-complete functional programming language.
Visual mappers
Finally, there are tools that display the mapping graphically and generate code — usually XSLT — underneath.
Part 3 — After 15 Years of Integration, Here’s What I Learned
Almost every integration project eventually asks the same question: which technology should we use for the mapping? My answer tends to disappoint people — it depends far less on features than on maintainability. After building integration platforms for more than fifteen years, I’ve become fairly opinionated about what that means in practice.
What I avoid
- General-purpose languages. Fine for something trivial, but they turn confusing fast once the mapping gets real — which, in my experience, is nine times out of ten. And they’re not portable: write the mapping in Java, and switching systems later means rewriting it from scratch.
- Templating languages. Same portability problem — a lot of integration platforms simply don’t support them, and they aren’t a good fit for structured data formats.
- Visual mappers. They look clean at first glance and become unreadable as complexity grows. The code they generate — Altova’s XSLT output is a good example — is often suboptimal and needlessly complex.
Why XSLT?
I mostly just choose XSLT. I didn’t land on XSLT because it’s fashionable — it’s the opposite of fashionable. I use it because, almost thirty years after its first release in 1998, it still runs practically everywhere. Write a stylesheet once and you can run the exact same file in Apache Camel, directly in Java or C#, in Mulesoft, in Apache NiFi… well you get the point.
It’s close to write-once-run-everywhere. That matters more than it sounds, because design time and development time are already slow and expensive — being able to reuse a mapping across systems is genuinely valuable over the long run.
Its age is also why the tooling and AI support around it are so mature. XSLT is well represented in what models have learned from, so AI can generate it fairly reliably, and it can be tested online or directly inside most integration platforms. The functional, declarative style takes some adjustment coming from procedural or object-oriented backgrounds — in a nice bit of irony, complex mappings in XSLT are often easier to express than the simple procedural things (variables, basic math) that feel natural elsewhere.
Two questions usually follow from this.
Why not just use AI directly for the mapping? Because AI is probabilistic — it can produce different output, or hallucinate, especially across model or version changes. There are mitigations, like tuning the temperature, but for now it’s not the right tool to run as the mapping itself. That may change once agent protocols like A2A and MCP combine with domain-specific languages — especially for speeding up the design-time phase — but it isn’t there yet.
What about JSON, since XSLT is XML-native? Its JSON support has grown over the years but is clearly an afterthought. DataSonnet, built on JSON/Jsonnet, handles this somewhat better. My own practical answer has been to convert everything to XML first, using Assimbly DocConverter — an open-source Java library I wrote that translates XML, JSON, CSV, and YAML into one another without needing complex schemas or marshalling, and can convert very large documents in milliseconds — then run the XSLT transformation from there.
Part 4 — The Future Isn’t AI. It’s AI + DSLs.
The common assumption is that AI will eventually replace mapping languages outright. I think the opposite is more likely.
Large language models are genuinely good at generating domain-specific languages — XSLT, DataWeave, JSONata, UTLX. They’re much less reliable when asked to act as the mapping engine itself at runtime, where determinism actually matters. Put differently: AI is shaping up to be the developer of the mapping, not the engine that runs it — which makes open, portable mapping languages more valuable, not less.
That’s what makes UTLX worth watching. Released as version 1.0 in April 2026 and introduced publicly at APIDays Amsterdam, it wasn’t designed around one format the way XSLT grew up around XML or DataSonnet around JSON — it started from first principles, treating every structured format as equal. It promises to be format-agnostic, schema-aware (XSD and JSON Schema support), open source, fast, and AI-friendly by design. It’s early — there’s no easy Maven dependency to embed yet — so whether it delivers on all of that remains to be seen.
But the direction feels right. A good travel adapter shouldn’t care which socket you started from — and increasingly, neither should a good mapping language.
