IVI 2.0 XML validation: four checks before release
IVI XML validation should answer four separate questions: can the file be read against the required schema, does it describe the correct vehicle, is the signed artifact verifiable, and what did the receiving system accept? Keep these results separate. One status called valid can conceal which checks have actually run.
1. Check syntax and the selected XSD
Begin with XML parsing, then validate against the complete schema package selected for the destination. Record the XSD version and retain the validator output. Investigate a wrong namespace, a missing required element, an invalid enumeration or an incorrect structure using the actual schema. The examples here are failure categories, not a substitute for the published IVI definition.
2. Compare the content with the vehicle record
A structurally correct file can still contain the wrong approval reference or stale source data. Ask the homologation reviewer to compare identity, type/variant/version, stage and applicable technical values with the controlled record. Give each discrepancy an owner and resolution. Correct the source or mapping and regenerate, so the evidence remains reproducible.
3. Verify the artifact that will be submitted
XML signature verification concerns the signed references and signature value. It does not establish the truth of every vehicle fact. Verify the final artifact using the destination's required profile and trust conditions, and retain the result alongside the file. Do not treat the presence of a signature element as a complete verification result.
4. Reconcile the receiving-system response
A transport response, a schema result and a business acceptance response may arrive at different stages. Identify which response is final for your destination. Link each attempt to its exact file and preserve rejection details. If a response is delayed, reconcile the existing attempt before deciding whether to retry.
Five useful tests for your pilot
- Missing data: remove a required value and confirm the issue is visible before release.
- Wrong approval: provide a structurally allowed but incorrect approval reference and confirm the source review catches it.
- Stale candidate: change the source after generation and confirm the earlier candidate is not silently released.
- Altered signed content: change a signed value and verify that integrity checking fails.
- Delayed response: simulate a submission with no final acknowledgement and check how the team reconciles its status.
Keep a validation record someone else can follow
Record the vehicle reference, source revision, candidate identifier, schema package, check time, result, error detail and accountable reviewer. Add the signed-file reference and receiving response when those stages occur. This small evidence chain makes it possible to explain why one vehicle is ready while another needs correction, without interpreting a general dashboard colour.
Which schema should the team use?
Obtain the current package from the responsible receiving route and record it in the implementation contract. EUCARIS links to IVI specifications; VCA publishes a UK-specific XSD. Test your agreed package rather than a schema fragment copied from a blog.