XBRL, construído como uma ontologia. Por isso diz onde e porquê.

O problema

O tempo vai-se à procura do que está errado.

Os validadores XBRL são muito bons a dizer que não. Raramente dizem onde, quase nunca porquê, e em vez de indicarem o que mudar devolvem-vos o trabalho.

• Chega um código de erro e nada diz de que ficheiro ou de que linha veio.
• Perceber o que significa obriga a uma viagem pela especificação.
• E mesmo sabendo o que está errado, continua sem se dizer o que mudar.
• Assim, cada dúvida da equipa de entrega acaba nos vossos programadores.
• E depois de uma atualização, o que ontem passava hoje falha em silêncio.

Integração

Os vossos ecrãs. O vosso fluxo de trabalho. O MirrorMere fica invisível.

Um ficheiro na vossa compilação e está feito. Cada especificação é um módulo à parte, por isso levam só as que tratam; e seja qual for a que apanhe um problema, a resposta volta na mesma 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();
    }
}