CEN/WS XBRL Kick-off meeting CWA2 status 26th October 2012 Emile Bartolé CWA2

Header Orientations Types of header fields Type of field Way of dealing with it Identifying context required for filing instances define « s » (= small) header taxonomy for this – main priority Transmission of signaletic metadata » define « cbv » (= core business vocabularies) oriented header taxonomy for this – secondary priority (if enough ressources remain for this) Transport related Not in the scope of the header taxonomy, this should be part of the submission system used Data related Not in the scope of the header taxonomy, this should be part of the data taxonomy CWA2

Header open issues Main Secondary Header format : Xml vs xbrl If XBRL, then taxonomy structure : Primaries – dimensional – tuples Secondary Cardinalities : can higher cardinalities be chosen for header taxonomy than in common business vocabulary ? Field sizes

Container orientations One single signature / encryption should be made on the container as a whole, not on individual XBRL instances contained therein Solution to work with both personal certificates as with company certificates

Container orientations Container security format: XADES - EPES is politically fully supported by the EU and referenced in all the documents gives as an output format an XML file that should be familiar to the XBRL community integrates the certificate used for signature, allowing fully automated treatment of submission containers allows the addition of multiple files to a single container

Alternative1: XML container <envelope> <header> <company>BankId01</company> <contactPerson> <name>Greta</name> <email>greta@bank01.eu</email> </contactPerson> <routingInfo> <report> <reportCode>COREP</reportCode> <version>testing</version> </report> </routingInfo> </header> <xbrl> .. instance 1 .. </xbrl> <xbrl> .. instance 2 .. </xbrl> </envelope>

Alternative1: XML container (2) Advantages - header information is retrieved immediately and communication with the declarer can start immediately. - XBRL validation starts after knowing the declarer and routing parameters: if XBRL validation fails, the application disposes of the header information to communicate with the declarer. This is not the case when only working with an XBRL instance: if validation fails, you may not have the header fact values because they are somewhere in the instance which failed. - this method enables the processing of multiple XBRL instances in one run. This is particularly useful when receiving instances from different periods or sub-reports. Smaller instances get validated faster. RH: A general advantage to having a separation between 'content' and envelope is that the content can be signed (encrypted) without bothering the transmission data. That is mostly the reason that with protocols like SOAP the whole of the instance is included in a single element (base64 encoded): transmission data is not affected that way. But prevent duplication; do not copy all the transmission data into the content too. That may lead to extra validations to ensure envelope and content are in sync. Open issues - encryption - compression

Alternative2: XADES-EPES / ZIP Signature & encryption (XADES-EPES) zip Header header.xbrl(xml?) Instances instance1.xbrl instance2.xbrl … instancen.xbrl Feedback instance1-feedback.xml instance2-feedback.xml instancen-feedback.xml Submission Container scope Feedback Container scope

Alternative2: XADES-EPES / ZIP Advantages Same as before + Sub-structuration via folders possible + Compression solved + Encryption / signature solved

Thanks for your attention emile.bartole@cssf.lu Comments or questions? Page 10 CWA2 10