XBRL, costruito come un'ontologia. Per questo dice dove e perché.

Il problema

Il tempo se ne va a caccia di che cosa non va.

I validatori XBRL sono bravi a dire di no. Raramente dicono dove, quasi mai perché, e invece di indicare che cosa cambiare vi rimandano indietro il lavoro.

• Arriva un codice d'errore, e nulla dice da quale file o da quale riga venga.
• Capire che cosa significhi richiede un giro nella specifica.
• E una volta capito che cosa non va, nessuno dice comunque che cosa cambiare.
• Così ogni domanda del team che deposita finisce ai vostri sviluppatori.
• E dopo un aggiornamento, ciò che ieri passava oggi fallisce in silenzio.

Integrazione

I vostri schermi. I vostri processi. MirrorMere resta invisibile.

Un file nella vostra build e avete finito. Ogni specifica è un modulo a sé, così prendete solo quelle che trattate; e qualunque sia a intercettare un problema, la risposta torna nella stessa forma.

// One result type, whichever specification produced it.
ValidationOutcome outcome = validator.validate(report);

if (!outcome.isValid()) {
    for (ValidationFinding f : outcome.errors()) {
        f.code();      // ixe:illegalMultipleUseOfId
        f.specRef();   // Inline XBRL 1.1, Section 4
        f.location();
    }
}