Su InfWorld ho trovato questa pagina dalla quale potete scaricare il podcast in formato mp3 della conversazione tra Jon Udell (mi ricordo la sua rubrica su Byte magazine) e Charles Hoffman, l'inventore di XBRL. Qualche anno fa, Udell non era stato tenero con XBRL, che aveva etichettato "a case study in complexity". Hoffman, nell'intervista, ha dato ragione a Udell su alcune sue critiche circa le scelte tecnologiche. Hoffman è un commercialista, non è un mago di XML e non voleva reinventare i linguaggi web: voleva reinventare la contabilità (e ci sta riuscendo).
In effetti XBRL non è un dialetto XML tipico. Le tecnologie XML anche avanzate, come XQuery, sono macchinose da usare sui documenti XBRL. Per fare un esempio, un'istanza di bilancio in XBRL riporta i valori delle voci all'interno di elementi xml ognuno dei quali ha un "element name" diverso, che corrisponde all'identificativo di quella voce nella tassonomia (ad esempio <Ricavi>2000</Ricavi>, <InteressiAttivi>21</Interessi attivi>. Il nome elemento dovrebbe invece essere l'equivalente di un nome tabella, quindi uguale per tutti i valori delle voci di bilancio (ad esempio sarebbe più semplice elaborare un'istanza che contenesse per i due valori di cui sopra <itemData "Ricavi">2000</itemData>, <itemData "InteressiAttivi">21</itemData>). Se importate un'istanza xbrl in excel, o in altri programmi che hanno una procedura di import da xml, ottenete una tabella con innumerevoli colonne, una per ogni voce di bilancio.
Per elaborare tassonomie e istanze xbrl serve quindi del software apposito che pre-elabori i file xbrl per portarli in una struttura tabellare o gerachica più leggera. La farraginosità del formato XBRL su file complica anche l'archiviazione di questi dati su database nativi XML.
Spero di non avervi annoiato. Con Davide Panizzolo stiamo lavorando ad un aggiornamento del materiale tecnico su XBRL, e lì approfondiremo queste osservazioni.
Luca
Nessun commento:
Posta un commento