Structured data (XML being one example, and JSON being another) has long been viewed as an optional nice-to-have-when necessary in the world of content development.
Now, with the Digital Product Passport looming on the horizon of European data regulations, structured data is likely about to become a critical must-have. And it might be happening sooner than some would like.
Mike introduced DPP as concept in the first installment of our interview. In Part Two we explored the inner mechanics of the protocol, and talked about the timelines and rollout expectations surrounding DPP.
In Part 3, Mike explains how those companies with structured data practices already in place should find themselves well-positioned to handle DPP implementation.
Structured Data and System Architecture
How do you think DPP will impact things like electronic parts catalogs and service documentation portals?
Well, that’ll be where the rubber meets the road for most engineering teams. Because, unfortunately, you can’t just bolt a DPP system onto your existing content infrastructure and call it done.
Audi’s MaterialLoop project provides a fascinating case study here. They’re not just implementing battery passports in isolation, they’re building a holistic vehicle passport that aggregates data from multiple component suppliers.
Okay, so it’s already happening.
It is. Tracking steel, aluminum, glass, tires, plastics, paints, you know. Textiles. And this will enable more efficient end-of-life vehicle processing.
What will this mean from a systems architecture perspective?
It will mean, I mean, for example, your electronic parts catalog suddenly needs to interface with blockchain traceability systems for raw materials. Same with supplier collaboration platforms for data validation.
I could see it wanting to work with automated sorting systems at recycling facilities. And regulatory reporting systems across multiple jurisdictions.
"Unfortunately, you can't just bolt DPP onto an existing infrastructure and say, 'OK, we're good, this will work how we want.'"
Let’s talk about the structured data foundation, then, of DPP. How do the teams you work with address this aspect of DPP?
Well, you know, that’s one of the more unique aspects of our company’s approach. All we deal in is structured data. We invested in structure, and we’ve been doing things this way for years. Obviously, when we started handling content development [in the 1990s] DPP was decades away from being a consideration.
We’ve perennially structured data for the purpose of automation and reuse of documentation, for things like electronic parts catalogs, digital distribution, different tool platforms and things like that.
But now, serendipitously, our approach has set our clients up very well for DPP.
And it’s something our newer clients enjoy, too, because just about the first thing we do with anyone’s data is organize it into these structures like XML and so forth.
So what’s good for documentation is going to be good for these new uses?
That’s right. Preparing product documentation for these uses I just mentioned is the same as preparing it for sorting it in an automated way for a recycling facility or regulatory reporting across different regions and jurisdictions.
The thing to understand is, you can’t just bolt DPP onto an existing infrastructure and say, “OK, we’re good, this will work how we want it.”
There’s always going to be something from an interface or integration standpoint where out-of-the-box probably won’t work and requires some sort of update to function properly.
From what you’ve seen, how prepared are Europe manufacturers for DPP? Do you think they’re way behind the 8 ball?
I think what’s interesting is how well Audi and Toyota have kicked off their work on the EV battery front.
Of the OEMs themselves, those two companies have really impressed me with their preparation.
XML and Structured Data
Is XML the only game in town for managing this kind of structuring properly?
[Laughs] I’m not going to use the term “only game in town”. Because I suppose anything is possible and there may be other ways to make it work.
I’d rather call XML kind of a “no-brainer”, right? Because it’s there, it’s proven, it plays nice with all the necessary automations. It’s well supported and we know it works properly.
So, for any company bracing for impact, it helps to find a supplier knows how to manage XML data for OEMs, is familiar with EU regulations, and stays on top of EU regulations—knowing full well that stateside adoption is imminent, too.
So many content developers seem to sleeping on DPP a bit.
[Laughs] A bit.
Why do you think folks might be dragging their feet on DPP?
Honestly, I can’t really speak to the motivations there. But I really don’t see anything DPP specific happening in the corners you’d expect.
It may be they’re not aware of it. There may be a kind of ‘wait and see’ attitude in play. Maybe they figure it’s better to adopt a reactive posture. I really don’t know.
In practice, though, it’s like the building code scenario I mentioned earlier. If I was building a house I’d much rather work with compliance in mind. It’s way better to work like that than build a house and have to go in and re-do a ton of stuff after the inspector shows up and declares it all non-compliant, right?
"Some teams already apply [XML and json] structure end-to-end as part of their fundamental process. Before this is done, that’s where we'll all need to be."
I’ll keep my own experiences with home inspection to myself here [laughs] but, yeah, I have to think that would be better.
And, don’t get me wrong. Regardless of the preparation everyone will face challenges around how to integrate their information into the other systems and platforms that are going to use it. But we can all count on data structure being an essential part of that battle, and those companies with structured data are not going to have to sort that out.
Data structure will be an unavoidable component of DPP regulation.
For my own understanding, how do companies handle this information if they’re not structuring it?
Well, I mean, short answer is only partially, right? Piecemeal. Ad hoc or as-needed.
I think the thing that is unique about the teams I work with here is the end-to-end application of structure.
Other companies may employ a level of structure, at times. But the approach is often pragmatic as opposed to being process-based. Maybe some of the copy is structured on an ad hoc basis, or maybe this piece of CAD is structured, but other pieces are not.
The teams I work with apply structure, be it XML or JSON, end-to-end and as part of their fundamental process. And that’s really the world everyone will have to migrate into before all is said and done.
Article Summary
Q1: Why is structured data essential for successful DPP implementation?
Structured data is the foundation that allows DPP systems to interface with multiple platforms—such as parts catalogs, supplier validation tools, regulatory systems, and recycling technologies. As the article explains, you can’t simply “bolt DPP onto existing infrastructure.” Without structured data, OEMs face integration gaps, compliance risks, and costly rework across their content and engineering environments.
Q2: How does structured data help OEMs prepare for global DPP regulations?
Because DPP is fundamentally about standardization, having structured data (such as XML or JSON) positions OEMs to meet EU requirements and makes it far more likely their data will comply as other regions adopt similar regulations. Companies already structuring their information end-to-end avoid the massive retrofits that reactive organizations will face when DPP becomes mandatory.
Q3: How does structured data reduce long-term engineering and documentation costs?
The article notes that structured data enables automation, reuse, and clean integration across electronic parts catalogs, service documentation portals, and downstream systems. This prevents the “rebuild everything later” scenario—similar to building a house with code compliance in mind. Teams that already work with structured data avoid expensive retroactive fixes once DPP workflows and audits arrive.
Q4: Why is structured data important for end-of-life processing and recycling systems?
As illustrated by Audi’s MaterialLoop initiative, DPP data must track materials such as steel, plastics, textiles, and glass. Structured data enables automated sorting, regulatory reporting, and material traceability across the full vehicle lifecycle. It becomes the connective tissue that lets recycling facilities, suppliers, and OEM systems interpret and act on the same information.
Q5: What risks do manufacturers face if their data is not fully structured?
According to the article, companies relying on ad-hoc or partially structured content will struggle to integrate their information into the broader DPP ecosystem. Inconsistent structures across documentation, CAD files, supplier inputs, and service content create bottlenecks and compliance vulnerabilities. OEMs ultimately must migrate to an end-to-end structured data approach to meet DPP demands reliably.
