European Filing Rules

From XBRLWiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 05:59, 8 May 2013 (edit)
Katrin (Talk | contribs)

← Previous diff
Revision as of 06:13, 8 May 2013 (edit)
Katrin (Talk | contribs)

Next diff →
Line 1: Line 1:
<span style="font-size:18pt">'''CEN Workshop Agreement'''</span> <span style="font-size:18pt">'''CEN Workshop Agreement'''</span>
-'''Status''': Working Group Working Draft<br/>+'''Status''': Working Group Working Draft
-'''CEN WS XBRL Experts''': Thierry Declerck (DFKI), Roland Hommes (Rhocon), Katrin Heinze (Deutsche Bundesbank)<br/>+ 
-'''Editing rules'''<br/>+'''CEN WS XBRL Experts''': Thierry Declerck (DFKI), Roland Hommes (Rhocon), Katrin Heinze (Deutsche Bundesbank)
-Editorial comments should be highlighted as follows:<br/>+ 
 +'''Editing rules'''
 + 
 +Editorial comments should be highlighted as follows:
<span style="background-color:yellow">A comment</span> <span style="background-color:yellow">A comment</span>
Line 24: Line 27:
=Introduction= =Introduction=
-The eXtensible Business Reporting Language (XBRL) specification provides a high degree of flexibility in the creation of XBRL instance documents. Part of this flexibility stems from the nature of the syntax: XML, and part stems from the XBRL specification itself. This document is providing a guidance for regulators, on the syntax used in XBRL instances, to enable them to make restrictions where they feel they are appropriate.+The eXtensible Business Reporting Language (XBRL) specification provides a high degree of flexibility in the creation of XBRL instance documents. The following set of rules are intended to recommend best practices on the freedom of choice for the benefit of clear guidance on preparation and validation of instance documents and an increase of interoperability between computer applications. They also facilitate the analysis and comparison of instance documents for preparers as well as receivers of XBRL in the reporting process.
-Disclaimer:<br/>+'''The filing rules represent a collection of recommendations to be seen as advisable to be implemented in the European supervisory reporting process. The rules are recommended to be adopted by national supervisors for other reporting purposes when they do not contradict their needs, i.e. footnotes are sometimes necessary to explain the content of reported fact. The listed filing rules are influenced by the European Taxonomy Architecture in cases where the instance creation is affected.'''
-'''The filing rules represent a collection of recommendations to be seen as an advice to be implemented in the European supervisory reporting process. The rules are also recommended to be adopted by national supervisors for other reporting purposes when they do not contradict their needs, i.e. footnotes are sometimes necessary to explain the content of reported fact. The listed filing rules are influenced by the European Taxonomy Architecture in cases where the instance creation is affected.'''+
-This document is listing best practices for the benefit of clear guidance on preparation and validation of XBRL instance documents and an increase of interoperability between computer applications that process these instances. +The purpose of these filing rules is minimize the reporting burden for reporting entities in Europe notwithstanding amendments to these rules would be optionally prescribed by one or more regulators.
-Consistent use of the best practices facilitates the analysis and comparison of XBRL instance documents for both reporting entities as well as receivers in the reporting process.+
-One goal of this document is to minimize the reporting burden for reporting entities in Europe. This goal is however subjective to reporting legislation as implemented by National and European regulators.+
Notwhitstanding the only authoritative restrictions are respectivelly the XBRL specifications and the regulatory instructions, the following set of rules helps to avoid unnecesary complications by adopting well stablished best practices. Notwhitstanding the only authoritative restrictions are respectivelly the XBRL specifications and the regulatory instructions, the following set of rules helps to avoid unnecesary complications by adopting well stablished best practices.
-The grammar used to express some of the best practices is tightly connected to the the environment these practices were developed. I.e. guidelines stemming from [http://www.ifrs.org/XBRL/Resources/Documents/GlobalFilingManual20110419.pdf Global Filing Manual] or [http://www.sec.gov/info/edgar/edmanuals.htm Edgar Filing Manual] are based on [http://www.ietf.org/rfc/rfc2119.txt RFC 2119].+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [http://www.ietf.org/rfc/rfc2119.txt RFC 2119].
-On the other hand the CEN projects are using the grammar from [http://cen.eurofiling.info/wp-content/upLoads/data/Drafting-CEN-ISO-deliverables-CommonRulesElements.2.0.pdf CEN T/C 123].+
-The guidance in this document is in the form of notes that will not make any strong texts on rules being a must/shall or should/recommended because it is not this document that has a mandate to put down rules. Only National and European regulators may have such a mandate. They can choose from the guidelines presented here to create their own set of rules.+This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “MUST” (strong recommendation), “SHOULD” or "RECOMMENDED" (recommendation) and “MAY” (possibility). Organizations wishing to implement this CWA (CEN Workshop Agreement) would be expected to consider all recommendations where the terms "MUST", “SHOULD” and "RECOMMENDED" are used.
==Objective== ==Objective==
-The primary objective of the CWA1 working group is interoperability, by harmonization and guidance in the XBRL taxonomy creation process as carried out by regulators, supervisory authorities, voluntary supply chains and others.+The primary objective is interoperability, by harmonization and guidance on the rules of XBRL taxonomy creation process carried out by regulators, supervisory authorities, voluntary suplly chains and others.
-The secondary objective is to facilitate adoption, by maintaining technological requirements when creating XBRL instance documents and keep them as simple as possible. +The secondary objective is facilitate adoption, by maintaining as simple as possible the technological requirements when creating XBRL instance documents.
-The fundamental use case that guides the following guidelines is the submission, by a reporting entity, of its regulatory filings, and the consumption of those regulatory filings by (several) reporting applications. +The fundamental use case that guides the following set of rules is the submission, by a reporting entity, of its regulatory filings, and the consumption of those regulatory filings by several reporting applications.
-The following texts provides guidance on the preparation and validation of instance documents in XBRL format. +The following set of rules provides guidance on the preparation and validation of instance documents in XBRL format.
-The guidelines in this document also aim to facilitate the analysis and comparison of reporting data as well as the interoperability of computer applications.+The rules in this document also aim to facilitate the analysis and comparison of reporting data as well as the interoperability of computer applications.
==Target Audience== ==Target Audience==
This document is intended for a technical audience and assumes that the reader has a working knowledge of the XBRL 2.1 and the XBRL Dimensions 1.0 Specifications and has a basic understanding of XML, Namespaces, and XML Schema. This document is intended for a technical audience and assumes that the reader has a working knowledge of the XBRL 2.1 and the XBRL Dimensions 1.0 Specifications and has a basic understanding of XML, Namespaces, and XML Schema.
-To readers with XML knowledge, many of the guidelines in this document will be familiar however, others originate from features that are XBRL-specific and therefore the reasoning behind them may be less obvious.+To readers with XML knowledge, many of the guidelines in this document will be familiar however, other rules originate from features that are XBRL-specific and therefore the reasoning behind these rules may be less obvious. Where appropriate, the rules are accompanied by a brief explanation.
-To ease the understanding by software developers implementing these guidelines in their reporting system, an UML model has been created to show the relationships between the different XBRL objects mentioned in this document.+To ease understanding for software developers implementing these rules in their reporting system, an UML model has been created to show the relationships between the different XBRL objects mentioned in this document.
==Relationship to Other Work== ==Relationship to Other Work==
Line 62: Line 61:
=Scope= =Scope=
-The guidelines in this document have been created for regulatory filings in the context of European supervisory reporting.+The rules in this document have been created for regulatory filings in the context of European supervisory reporting.
In this document, “regulatory filings” encompasses European reporting standards that are published by an European supervisory authority and accompanied by an XBRL taxonomy as well as extensions on these taxonomies provided by national supervisors. In this document, “regulatory filings” encompasses European reporting standards that are published by an European supervisory authority and accompanied by an XBRL taxonomy as well as extensions on these taxonomies provided by national supervisors.
Line 95: Line 94:
;XML : eXtensible Markup Language ;XML : eXtensible Markup Language
-=Guidelines=+=Rules=
-==File based guidelines==+==Filing syntax rules==
<ul> <ul>
-<li><span style="color:blue; font-weight:bold">1.01 &nbsp;&nbsp;</span>'''File naming'''+<li><span style="color:blue; font-weight:bold">1.01 &nbsp;&nbsp;</span>
 +'''The file name of an instance document SHOULD follow the rules of the national filing system.'''
<br/> <br/>
-Different naming conventions exist around the world, essentially these are conveying some kind of meaning about: the sender, the reported filing and/or the reported period. For software that is storing the file name of the instance in a relational database some restrictions on which characters may be used and the total length of the file name may be appropriate.+There is no prescribed way of handling instance document file names. Different naming conventions exist around the world, mostly conveying some kind of meaning about the sender, the reported filing or reported period.</li>
-<br/>+<li><span style="color:blue; font-weight:bold">1.02&nbsp;&nbsp;</span>
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: Common practice is to use the extension .xml or .xbrl for instance documents, but there is no technical restriction to use anything else. There are no restrictions on filenames posed.+'''Reporting entities SHOULD use one of the taxonomies as specified in the filing system as the applicable taxonomy.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.1.5}</span><br/>
-<span style="color:blue; font-weight:bold">GFM 1.1.1</span>: XBRL document names MUST be unique in the reporting system.+A listing of all taxonomy files respective modules recognised in the filing system should be provided on a web location.
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.1.4</span>: XBRL document names are case sensitive.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.3.3</span>: XBRL document names must match {base}-{date}[_{suffix}].{extension}, (which results in {base}-{date}.xml for XBRL instances).+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.3.7</span>: XBRL document names are case sensitive.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.1.3</span>: XML files with 'xbrl' as the root node SHOULD have the file extension .xbrl.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.1.4</span>: The names of files that contain XBRL instances SHOULD NOT contain characters with different meanings across platforms.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''Rules about the file name of an instance document are to be set by the receiver of the reports.'''+
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">1.03&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">1.02 &nbsp;&nbsp;</span>'''Taxonomy selection'''+'''The encoding of all instance documents SHOULD be "UTF-8".'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.1.8}</span><br/>
-The reporter needs to be made aware on which taxonomy the instance should be created. A listing of all taxonomy files respective modules recognised in the filing system should be provided.+Several standards exist on the representation and handling of text. Some of the standards like ISO-8859-1 are widely used in various countries but the standards itself are largely incompatible with each other. UTF-8 is the preferred and most used encoding in HTML documents and therefore defined as Best Practice. It is necessary to specify the encoding attribute in the prologue of an instance document.<br/>
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification has defined the link:schemaRef and link:linkbaseRef nodes inside the instance to carry an URL that points from the instance to the taxonomy, but it has no mechanism to inform the reporter what its content should be.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.1.5</span>: Filers must use one of the taxonomies as specified in the disclosure system as their standard taxonomy.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.3.9</span>: Filers must use one of the taxonomies as specified on the SEC website as their standard taxonomy.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.2.1</span>: If a taxonomy schema document has an authoritative location, it must be referred to by that location.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''Reporting entities are recommended to use one of the taxonomies as specified in the filing system as the applicable taxonomy.'''+
-<br/>+
-</li>+
-<br/>+
-<li><span style="color:blue; font-weight:bold">1.03 &nbsp;&nbsp;</span>'''Character encoding of XBRL instance documents'''+
-<br/>+
-An XBRL instance document contains characters. Depending on the region in the world a multitude of characters could be interpreted as the (local) standard. If no rules are set arabic, kanji, cyrillic and latin could all be used in a single document.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The W3C XML characterset is Unicode (ISO 10646). It allows however all standardized charactersets as long as they appropriately declared in the XML document. IANA lists all recognized charactersets [http://www.iana.org/assignments/character-sets/character-sets.xml here].+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.1.8</span>: Encoding of all XBRL documents must be "UTF-8".+
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.1.3</span>: Characterset encoding "UTF-8" MUST be used.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''"UTF-8" is the recommended encoding for XBRL instance documents.'''+
-<br/>+
</li> </li>
'''context''' xmlDocument '''inv''': '''context''' xmlDocument '''inv''':
self.encoding = 'UTF-8' self.encoding = 'UTF-8'
 +<li><span style="color:blue; font-weight:bold">1.04&nbsp;&nbsp;</span>
 +'''Reporting entities SHOULD use only one of entrypoint schemas as specified in the applicable taxonomy.'''
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">1.04 &nbsp;&nbsp;</span>'''Taxonomy entrypoint selection'''+It is recommended to refer to a single entrypoint in an instance document and therefore include only one link:schemaRef element.
-<br/>+<span style="color:green; font-weight:bold">This is because the data point modelled taxonomies MAY contain multiple tables but these are not treated as an entrypoint. Only the whole of the taxonomy has a single entrypoint for all tables. Through the 'FilingIndicators' it is communicated which tables are communicated in the instance.</span></li>
-A published taxonomy can be discovered through entrypoints, which are defined by the taxonomy author. If multiple entrypoints are available in a single taxonomy the taxonomy author needs to provide clarification to the reporter, which entrypoint is to be used for which report. If multiple reports are allowed to be reported within a single instance problems may arise upon processing because the reported facts in the instance do not point to the entrypoint used.+<li><span style="color:blue; font-weight:bold">1.05&nbsp;&nbsp;</span>
-Data point modelled taxonomies may contain multiple tables but these are not treated as an entrypoint. Only the whole of the taxonomy has a single entrypoint for all tables. Through the 'FilingIndicators' it is communicated which tables are communicated in the instance.+'''Instance documents MUST be XBRL 2.1 and XBRL Dimensions 1.0 valid.'''
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification allows for multiple schema and/or linkbase references inside a single instance.+
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.2.1</span>: The link:schemaRef node MUST NOT appear more than once.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''Reporting entities are recommended to use only one entrypoint schema, as specified in the applicable taxonomy, per XBRL instance.'''+
-<br/>+
-</li>+
-<br/>+
-<li><span style="color:blue; font-weight:bold">1.05 &nbsp;&nbsp;</span>'''Valid XML-XBRL'''+
-<br/>+
-Each XBRL instance in the filing is tested separately for XBRL 2.1 and XDT 1.0 validity. In order to increase the likelihood that instance documents pass validation, filers are encouraged to validate their compliance with the XBRL 2.1 and Dimensional 1.0 specification prior to submission.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: XML and XBRL aware processors will test each instance against their specifications. There is no rule that invalid instances may not be processed.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 2.1.1</span>: The XBRL instance documents in a filing must be XBRL 2.1 and XBRL Dimensions 1.0 valid.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.4.3</span>: The XBRL instance documents in a submission must be XBRL 2.1 valid.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''Instance documents are required to be XBRL 2.1 and XBRL Dimensions 1.0 valid.'''+
<br/> <br/>
 +Each instance document in the filing is tested separately for XBRL 2.1 validity. In order to increase the likelihood that instance documents pass validation, filers are encouraged to validate their compliance with the XBRL 2.1 Specification prior to submission.
</li> </li>
'''context''' Instance::isXBRLValid() : Boolean '''context''' Instance::isXBRLValid() : Boolean
'''post''': result = true '''post''': result = true
-<br/>+<li><span style="color:blue; font-weight:bold">1.06&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">1.06 &nbsp;&nbsp;</span>'''Valid XBRL Formulae'''+'''The instance documents SHOULD be valid with regards to XBRL Formula as defined in the applicable taxonomy.'''
<br/> <br/>
Any formula linkbase discovered by the XBRL software from opening the entrypoint can contain tests on the quality of the reported data. The tests that report an error on these data SHOULD be corrected. There MAY be tests that produce only warnings. Solving these warnings depends on the message content and the filer perspective on them. Any formula linkbase discovered by the XBRL software from opening the entrypoint can contain tests on the quality of the reported data. The tests that report an error on these data SHOULD be corrected. There MAY be tests that produce only warnings. Solving these warnings depends on the message content and the filer perspective on them.
-<br/> 
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: If the XBRL Formula linkbase is discovered by the XBRL enabled software, and it has the capacity to execute assertions as defined in the XBRL Formula specification, these will result in true/false statements. Whether this points to an error situation in the instance is determined by the formula author, who may clarify the situation found in a message. There are no rules preventing processing of XBRL instances that contain formulae errors. 
-<br/> 
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to have the XBRL instance document valid with regards to XBRL Formula as defined in the applicable taxonomy.''' 
-<br/> 
</li> </li>
'''context''' Instance::isFormulaValid() : Boolean '''context''' Instance::isFormulaValid() : Boolean
'''post''': result = true '''post''': result = true
 +<span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-14|Comment-14]]</span>
 +<li><span style="color:blue; font-weight:bold">1.07&nbsp;&nbsp;</span>
 +<span style="color:green; font-weight:bold">'''Reports MUST contain only concepts created by the taxonomy author.'''</span>
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">1.07 &nbsp;&nbsp;</span>'''Taxonomy extensions by reporters'''+XBRL Taxonomies can be extended by anybody with the proper technical knowledge. Filings to European Regulatory Authorities are 'closed form' i.e. all data points allowed by the regulator are in the taxonomy. There can be no extension of the taxonomy by reporters to report more data points to the regulator.
-<br/>+
-XBRL Taxonomies can be extended by anybody with the proper technical knowledge. Filings to European Regulatory Authorities are 'closed form' i.e. all data points allowed by the regulator are in the taxonomy. There can be no extension of the taxonomy by reporters to report more data points to the regulator. However national supervisors may extend European taxonomies. For reporters the combination of base and extension taxonomies are regarded as a single taxonomy.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: Extension of taxonomies is part of the core specification of both XML and XBRL.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM</span>: Extensions are expected.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM</span>: Extensions are mandated.+
-<br/>+
-<span style="color:blue; font-weight:bold">SBR</span>: Extensions are prohibited.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''Reports are required to contain only concepts created by the taxonomy author.'''+
-<br/>+
</li> </li>
'''context''' Taxonomy '''inv''': '''context''' Taxonomy '''inv''':
self.owner = ‚European Banking Authority’ self.owner = ‚European Banking Authority’
'''or''' self.owner = ‚European Insurance and Occupational Pensions Authority’ '''or''' self.owner = ‚European Insurance and Occupational Pensions Authority’
 +
 +<li><span style="color:blue; font-weight:bold">1.08&nbsp;&nbsp;</span>
 +'''Reporters SHOULD always send the full applicable dataset for an entrypoint schema in an instance document.'''
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">1.08 &nbsp;&nbsp;</span>'''Completeness of the instance'''+In case of corrections it is recommended not to send partial data with just the corrected facts. Non-complete submissions could lead to invalid instance documents and might raise conflicts with already processed data in the reporting system of the receiver.
-<br/>+
-In case corrections are needed on filings that already have been sent, it is recommended not to send partial data with just the corrected facts. Non-complete submissions could lead to invalid instance documents (according to either XBRL 2.1, XDT 1.0 or appropriate Formulae) and might raise conflicts with already processed data in the reporting system of the receiver.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: No restrictions on the instance content other than it being XML and XBRL valid.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that reporters always send the full applicable dataset for an applicable entrypoint schema in an instance document.'''+
-<br/>+
</li> </li>
</ul> </ul>
-==Instance syntax guidelines==+<span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-12|Comment-12]]</span>
 + 
 +==Instance syntax rules==
<ul> <ul>
-<li><span style="color:blue; font-weight:bold">2.01 &nbsp;&nbsp;</span>'''@xml:base'''+<li><span style="color:blue; font-weight:bold">2.01&nbsp;&nbsp;</span>
-<br/>+'''Attribute @xml:base SHOULD NOT appear in any instance document.'''
-XML processors interpret this attribute differently, and there is no semantic need for this attribute.+<span style="color:green; font-weight:bold">{GFM 1.1.7}</span><br/>
-<br/>+XML processors interpret this attribute differently, so it should not be used.
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The attribute xml:base may be inserted in XML documents to specify a base URI other than the base URI of the document or external entity.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.1.7</span>: Attribute xml:base must not appear in any filing document.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.3.11</span>: Attribute xml:base must not appear in any Interactive Data Document.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that the attribute @xml:base not appear in any instance document.'''+
-<br/>+
</li> </li>
'''context''' xmlDocument '''inv''': '''context''' xmlDocument '''inv''':
self.element->select(xml:base)->isEmpty() self.element->select(xml:base)->isEmpty()
 +<li><span style="color:blue; font-weight:bold">2.02&nbsp;&nbsp;</span>
 +'''link:schemaRef MUST contain the full URL as published on the internet'''
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.02 &nbsp;&nbsp;</span>'''xbrli:xbrl/link:schemaRef content'''+The version of any report is represented in folder names, not in URI namespaces. To correctly interpret the reported facts the proper entrypoint schema and its taxonomy must be present in the instance by including the full path (including the folder with the version indicator in it) in the link:schemaRef element.
-<br/>+
-The version of any report is represented in folder names, not in URI namespaces. To correctly interpret the reported facts the proper entrypoint schema and its taxonomy must be present in the instance by including the full path (including the folder with the version indicator in it) in the link:schemaRef node.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The link:schemaRef is optional according to its defining schema. It can contain xs:anyURI content.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.1.3</span>: The URI content of the xlink:href attribute, the xsi:schemaLocation attribute and the schemaLocation attribute must be relative and contain no forward slashes, or a recognized external location of a standard taxonomy schema file, or a '#' followed by shorthand xPointer.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.3.6</span>: The URI content of the xlink:href attribute, the xsi:schemaLocation attribute and the schemaLocation attribute must be relative and contain no forward slashes, or a recognized external location of a standard taxonomy schema file, or a '#' followed by shorthand xPointer.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have the link:schemaRef contain the full URL as published on the internet.'''+
-<br/>+
</li> </li>
 +<li><span style="color:blue; font-weight:bold">2.03&nbsp;&nbsp;</span>
 +'''xmlversion in the instance MUST be 1.0 '''
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.03 &nbsp;&nbsp;</span>'''@xmlversion'''+Although version 1.1 exists, XBRL instances MUST be based on version 1.0.
-<br/>+
-Although version 1.1 exists, the whole of the XBRL specification is based around XML version 1.0. Unexpected results with XML enabled software can occur if the instance is based on XML version 1.1, even if no actual XML constructs from this version are used in the instance document.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: XML allows both versions to occur. XML enabled software is expected to perform validation according to the version indicated in this attribute.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to use @xmlversion=1.0.'''+
-<br/>+
</li> </li>
'''context''' xmlDocument '''inv''': '''context''' xmlDocument '''inv''':
self.version = '1.0' self.version = '1.0'
-<br/>+<li><span style="color:blue; font-weight:bold">2.04&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.04 &nbsp;&nbsp;</span>'''Use of namespace prefix'''+'''Declared namespace prefixes SHOULD be used'''
<br/> <br/>
Declaring unused namespaces is uncalled for and clutters the instance document. Declaring unused namespaces is uncalled for and clutters the instance document.
-<br/> 
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: There is no rule that mandates that declared namespace prefixes are actually used. It is mandatory to declare namespace prefixes that are being used. 
-<br/> 
-<span style="color:blue; font-weight:bold">FRIS 2.1.7</span>: Unused namespace declarations SHOULD NOT appear in XBRL instances 
-<br/> 
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to actually use namespace prefixes once they have been declared in the instance document.''' 
-<br/> 
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">2.05&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.05 &nbsp;&nbsp;</span>'''Re-use of namespace prefix's'''+'''Declared namespace prefixes SHOULD mirror the namespace prefixes as defined by schema author(s)'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.28}</span><br/>
-Most schema authors provide a namespace prefix for their targetNamespace. It is common practice to re-use these prefixes in other XML documents when needed. It may lead to confusion to human readers to see common understood prefixes used on a different namespace. Eg. the prefix 'xs' for the http://xbrl.org/2003/xbrl-instance-2033-12-31 namespace.+The W3C, XBRL International and the taxonomy author all assign namespace prefixes to their schema's. Human interpretation of the instance could be confused when these namespace prefixes are not followed in the instance.
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: Namespace prefixes are free te determine in any XML document, processing of XML nodes is tied to namespaces, not to namespace prefixes.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.28</span>: Instance document must use the same namespace prefixes as used in the XBRL schemas or conformance suite instances together with the recommended default namespace prefix for all namespaces.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.1.5</span>: XBRL instances SHOULD use the same namespace prefixes as used in the XBRL schemas or conformance suite instances+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that declared namespace prefixes mirror the namespace prefixes as defined by their schema author(s).'''+
-<br/>+
</li> </li>
 +<li><span style="color:blue; font-weight:bold">2.06&nbsp;&nbsp;</span>
 +<span style="color:green; font-weight:bold">'''There MUST be only one link:schemaRef in an instance'''</span>
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.06 &nbsp;&nbsp;</span>'''xbrli:xbrl/link:schemaRef repetition'''+Taxonomy authors will make sure that a single entrypoint schema needs to be referred to in the instance. This entrypoint will refer all required data points.
-<br/>+
-Taxonomy authors will make sure that a single entrypoint schema needs to be referred to in the instance. This entrypoint will refer all required data points. (See also 1.04)+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The link:schemaRef is optional and can be repeated unbounded times, according to its defining schema. +
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.2.1</span>: An instance MUST contain link:schemaRef only once.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have only one xbrli:xbrl/link:schemaRef node in any XBRL instance document.'''+
-<br/>+
</li> </li>
'''context''' Instance '''inv''': '''context''' Instance '''inv''':
self.SchemaReference->size() = 1 self.SchemaReference->size() = 1
 +<li><span style="color:blue; font-weight:bold">2.07&nbsp;&nbsp;</span>
 +<span style="color:green; font-weight:bold">'''There MUST be only link:schemaRef nodes to refer to external files'''</span>
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.07 &nbsp;&nbsp;</span>'''xbrli:xbrl/link:linkbaseRef'''+Entrypoints will be defined by means of a schema, and considering footnote linkbases are not allowed, there is no use for link:linkbaseRef.
-<br/>+
-Entrypoints will be defined by means of a schema, and considering footnote linkbases are not supported, there is no use for link:linkbaseRef.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The link:linkbaseRef is optional and can be repeated unbounded times, according to its defining schema. +
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.3.1</span>: An instance MUST NOT contain any link:linkbaseRef.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to refer to the taxonomy from the instance only by means of the link:schemaRef node.'''+
-<br/>+
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">2.08&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.08 &nbsp;&nbsp;</span>'''XML comment and documentation'''</span>+<span style="color:green; font-weight:bold">'''The instance SHOULD only contain contexts, units, schemaRefs and facts.'''</span>
<br/> <br/>
Verbose comments inside the instance that do not get reported as a fact will be ignored by the regulator. These comments clutter the instance and have no use to the regulator. Verbose comments inside the instance that do not get reported as a fact will be ignored by the regulator. These comments clutter the instance and have no use to the regulator.
-<br/> 
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XML specification allows for unlimited number of XML comments, xs:annotation/xs:documentation nodes and processing instructions. 
-<br/> 
-<span style="color:blue; font-weight:bold">FRIS 2.1.11</span>: An XBRL instance creator MAY include XML comments within an XBRL instance, but MUST NOT assume that the XBRL instance consumer will use the comments 
-<br/> 
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that an instance contains only contexts, units, schemaRefs and facts.''' 
-<br/> 
-</li> 
-<br/> 
-<li><span style="color:blue; font-weight:bold">2.09 &nbsp;&nbsp;</span>'''Reserved''' 
-<br/> 
</li> </li>
 +
</ul> </ul>
-=== Context related guidelines === +=== Context related rules ===
 +<span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-23|Comment-23]]</span>
 + 
<ul> <ul>
-<li><span style="color:blue; font-weight:bold">2.10 &nbsp;&nbsp;</span>'''Duplicates of xbrli:xbrl/xbrli:context'''+<li><span style="color:blue; font-weight:bold">2.10&nbsp;&nbsp;</span>
-<br/>+'''It SHOULD be avoided to have duplicates of xbrli:xbrl and xbrli:context elements.'''
-Duplication is formed if all children nodes and values of the xbrli:context node with the exception of the @id on the context itself, are the same. For the two sub-elements of xbrl:context xbrli:segment and xbrli:scenario elements extra rules apply in that they are tested for equality of their children without regard to the order of their children. Contexts are defined to be equivalent if they have S-equal identifiers, equal dateUnion values for startDate, endDate and instant (respectively), and segment or scenario element children with equal QNames for each explicit and/or typed dimension.+<span style="color:green; font-weight:bold">{GFM 1.2.7}</span><br/>
-Duplicated contexts do not express extra semantics and potentially disturb comparison of facts that point to any of the duplicated occurences.+An instance document must not contain equivalent xbrli:context elements.The two sub-elements of xbrl:context xbrli:segment and xbrli:scenario elements are tested for equality of their children without regard to order. Contexts are defined to be equivalent if they have S-equal identifiers, equal dateUnion values for startDate, endDate and instant (respectively), and segment or scenario element children with equal QNames for each explicit dimension.
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: XML allows duplicate nodes. No processing or semantic relevancy to the order found are being made. XBRL has described multiple types of 'equalities', these are described in the XBRL 2.1 specification, but the ones appearing in instances are not prohibited.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.7</span>: An instance must not contain duplicate xbrli:context elements.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.7</span>: An instance must not contain duplicate xbrli:context elements.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.4.1</span>: An instance MUST NOT contain s-equal contexts.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to avoid having duplicates of xbrli:xbrl/xbrli:context nodes.'''+
-<br/>+
</li> </li>
'''context''' Context '''inv''': '''context''' Context '''inv''':
Line 361: Line 219:
'''and''' c1.Identifier.scheme <> c2.Identifier.scheme '''and''' c1.Identifier.scheme <> c2.Identifier.scheme
'''and'''(c1.Period.start <> c2.Period.start '''and''' c1.Period.end <> c2.Period.end '''or''' c1.Period.instant <> c2.Period.instant) '''and'''(c1.Period.start <> c2.Period.start '''and''' c1.Period.end <> c2.Period.end '''or''' c1.Period.instant <> c2.Period.instant)
 +
 +<li><span style="color:blue; font-weight:bold">2.11&nbsp;&nbsp;</span>
 +<span style="color:green; font-weight:bold">'''Id attributes SHOULD represent non semantic relevant content.'''</span>
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.11 &nbsp;&nbsp;</span>''' xbrli:xbrl/xbrli:context/@id'''+Even though there is no limitation on the length of an id attribute it is recommended to keep it as short as possible. Id attributes should also be abstract. <span style="color:green; font-weight:bold">Id attributes are used for XML internal pointers only.</span>
-<br/>+
-The id attribute is meant as unique technical key within a XML document. Conveying semantics in the id attribute will go lost when the XML content is stored in a database (which generally work with their own keys). Even though there is no limitation on the length of an id attribute it is recommended to keep it as short as possible. +
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: XML prohibits duplicated @id in a single document. Their is no length restriction for the @id. An @id uniquely identifies an element in an XML document. The data type for @id is xs:NCName.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.4.3</span>: Context id attribute values SHOULD be meaningful to a reader of the primary language of the instance+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to refrain from expressing semantics in the xbrli:context/@id node.'''+
-<br/>+
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">2.12&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.12 &nbsp;&nbsp;</span>'''Unused xbrli:xbrl/xbrli:context'''+'''There MUST NOT be unused xbrli:context.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.8}</span><br/>
-Unused contexts (contexts which are not referred to by facts) clutter the instance and add no value to either regulator or reporter.+Unused contexts (contexts which are not referred to by facts) clutter the instance and add no value.
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: XML and XBRL do not prohibit the existence of non referenced context nodes.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.8</span>: Every xbrli:context element must appear in at least one contextRef attribute in the same instance.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.8</span>: Every xbrli:context element must appear in at least one contextRef attribute in the same instance.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.4.2</span>: An XBRL instance SHOULD NOT contain unused contexts+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to prevent unused xbrli:context nodes to be present in the instance.'''+
-<br/>+
</li> </li>
'''context''' Context '''inv''': '''context''' Context '''inv''':
self.Fact.allInstances()->notEmpty() self.Fact.allInstances()->notEmpty()
-<br/>+<li><span style="color:blue; font-weight:bold">2.13&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.13 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:context/xbrli:identifier/@scheme'''+'''xbrli:identifier/@scheme MUST follow the pattern recognised in the filing system.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.1}</span><br/>
-The @scheme contains a meanigfull string to the the regulator receiving the instance. Often this string represents an URI which refers to a list of issued keys to all reporters.+It is recommended to use a proprietary national id code with the scheme refering to the corresponding national central bank. <br/>
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification mandates the @scheme attribute to contain xs:anyURI content.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.1</span>: The scheme attritbute of the xbrli:identifier element must follow the pattern recognised in the disclosure system.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.1</span>: The scheme attritbute of the xbrli:identifier element must be http://www.sec.gov/CIK.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.5.1</span>: Existing authoritative identifier schemes SHOULD be used.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to use a code or pattern corresponding with the scheme that is prescribed by the national or European regulator that is receiving the XBRL instance.'''+
-<br/>+
</li> </li>
Example: <xbrli:identifier scheme="http://www.kredittilsynet.no">NO12345678</xbrli:identifier> Example: <xbrli:identifier scheme="http://www.kredittilsynet.no">NO12345678</xbrli:identifier>
Line 412: Line 242:
'''context''' Context '''inv''': '''context''' Context '''inv''':
self.Identifier.allInstances()->forAll(scheme = schemeURL) self.Identifier.allInstances()->forAll(scheme = schemeURL)
-<br/>+ 
-<li><span style="color:blue; font-weight:bold">2.14 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:context/xbrli:identifier'''+<li><span style="color:blue; font-weight:bold">2.14&nbsp;&nbsp;</span>
-<br/>+'''xbrli:identifier MUST have a number or identifier recognised in the filing system as its content.'''
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification allows for any content in the xbrli:identifier node.+<span style="color:green; font-weight:bold">{GFM 1.2.2}</span><br/>
-<br/>+See explanation on rule 2.13
-<span style="color:blue; font-weight:bold">GFM 1.2.2</span>: An xbrli:identifier element must have a number or identifier recognised in the disclosure system as its content.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.2</span>: An xbrli:identifier element must have the CIK of the registrant as its content.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to use a number or identifier recognoised in the filing system of the regulator.'''+
-<br/>+
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">2.15&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.15 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:context/xbrli:identifier repetition'''+'''All xbrli:identifier content MUST be identical.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.3}</span><br/>
There can only be one reporter of an instance. Even if the content of the instance deals with a group of companies, there is only one entity reporting the instance to the regulator. There can only be one reporter of an instance. Even if the content of the instance deals with a group of companies, there is only one entity reporting the instance to the regulator.
-<br/> 
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification allows for only one xbrli:identifier per xbrli:context, but unlimited number of xbrli:contexts in an XBRL instance. 
-<br/> 
-<span style="color:blue; font-weight:bold">GFM 1.2.3</span>: All xbrli:identifier elements in an instance must have identical content. 
-<br/> 
-<span style="color:blue; font-weight:bold">EFM 6.5.3</span>: All xbrli:identifier elements in an instance must have identical content. 
-<br/> 
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have all xbrli:identifier content to be identical.''' 
-<br/> 
</li> </li>
'''context''' Context '''inv''': '''context''' Context '''inv''':
self.Identifier.allInstances()->forAll(i1, i2| self.Identifier.allInstances()->forAll(i1, i2|
i1 = i2 '''implies''' i1.value = i2.value) i1 = i2 '''implies''' i1.value = i2.value)
 +<li><span style="color:blue; font-weight:bold">2.16&nbsp;&nbsp;</span>
 +'''All xbrli:identifier/@scheme content MUST be identical.'''
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.16 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:context/xbrli:identifier/@scheme repetition'''+The scheme attribute MUST correspond to the identifier of the reporting entity and there can only be one scheme defined for the reporting entity in an instance document.
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification allows for only one xbrli:identifier/@scheme per xbrli:context, but unlimited number of xbrli:contexts in an XBRL instance.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have all xbrli:identifier/@scheme content to be identical.'''+
-<br/>+
</li> </li>
'''context''' Context '''inv''': '''context''' Context '''inv''':
self.Identifier.allInstances()->forAll(i1, i2| self.Identifier.allInstances()->forAll(i1, i2|
i1 = i2 '''implies''' i1.scheme = i2.scheme) i1 = i2 '''implies''' i1.scheme = i2.scheme)
-<br/>+<li><span style="color:blue; font-weight:bold">2.17&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.17 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:context/xbrli:period/*'''+'''All xbrli:xbrl/xbrli:context/xbrli:period date elements MUST have ccyy-mm-dd format.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.25}</span><br/>
-European regulators will allow only dates to represent the reporting period.+The XBRL specification of this element has made it possible to enter a date or a dateTime. European regulators only allow dates.
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification of this element has made it possible to enter a xs:date or a xs:dateTime on any of the date nodes that are a child to xbrli:period.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.25</span>: Dates in period element of the context must comply with yyyy-mm-dd format. No time is allowed in the value for dates.+
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.5.2</span>: An instance MUST NOT have xbrli:period nodes containing time details.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have all the xbrli:period date elements expressing ccyy-mm-dd format only.'''+
-<br/>+
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">2.18&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.18 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:context/xbrli:period/xbrli:forever'''+'''xbrli:xbrl/xbrli:context/xbrli:period/xbrli:forever MUST NOT exist.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.30}</span><br/>
The extreme version of duration is 'forever'. The XBRL specification has created this to solve problems with dates starting 'at the beginning' and ending 'never'. E.g. the name of the filer has in general no end date. The regulator is only interested in type of data for the reported time segment that has a defined starting and ending date. The extreme version of duration is 'forever'. The XBRL specification has created this to solve problems with dates starting 'at the beginning' and ending 'never'. E.g. the name of the filer has in general no end date. The regulator is only interested in type of data for the reported time segment that has a defined starting and ending date.
-<br/> 
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification allows for xbrli:forever (as a QName) to be used as alternative to xbrli:instant or the combination of xbrli:startDate and xbrli:endDate. 
-<br/> 
-<span style="color:blue; font-weight:bold">GFM 1.2.30</span>: A context must not contain the xbrli:forever element. 
-<br/> 
-<span style="color:blue; font-weight:bold">SBR 2.5.3</span>: An instance context MUST NOT use xbrli:forever. 
-<br/> 
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required not allowing xbrli:forever as a valid reporting period.''' 
-<br/> 
</li> </li>
'''context''' Context '''inv''': '''context''' Context '''inv''':
self.Period.forever->isEmpty() self.Period.forever->isEmpty()
-<br/>+<li><span style="color:blue; font-weight:bold">2.19&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.19 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:context/xbrli:period/xbrli:startDate and xbrli:endDate equality'''+'''xbrli:startDate and xbrli:endDate in the same context MUST NOT have the same date.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.9}</span><br/>
-When the values in xbrli:startDate and xbrli:endDate in the same or consecutive contexts are equal, it may be unclear what the exact reporting period is. If however consecutive 24 hour reporting periods are allowed by the regulator, explicit guidelines on interpreting the context reporting periods must be provided.+Note that XBRL 2.1 interprets a date used as a context start date as “midnight at the beginning of” that day. A date used as an instant or endDate in a context means “midnight at the end of” that day.
-<br/>+<span style="color:yellow; font-weight:bold">Actually this rule prohibits 24 hour reporting periods. See EFM V22 rule 6.5.9</span></li>
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification has a semantic interpretation that a date used as a context/startDate as ''midnight at the beginning of'' that day. A context/instant or context/endDate means ''midnight at the end of'' that day.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.9</span>: The same date must not appear as the content of both an xbrli:startDate and an xbrli:endDate in an instance.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.9</span>: +
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.5.1</span>: An instance MUST NOT contain contexts where xbrli:periodEnd value of any context equals xbrli:periodStart value of another context.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended not allowing equal xbrli:startDate and xbrli:endDate values.'''+
-<br/>+
-</li>+
Example: a company reporting at a May 31st, 2009 fiscal year-end will have contexts whose end date-time is Example: a company reporting at a May 31st, 2009 fiscal year-end will have contexts whose end date-time is
midnight at the end of 2008-05-31 (the prior fiscal year) and contexts whose start date-times are midnight at the midnight at the end of 2008-05-31 (the prior fiscal year) and contexts whose start date-times are midnight at the
Line 505: Line 288:
'''context''' Context '''inv''': '''context''' Context '''inv''':
self.Period->select(start < end)->notEmpty() self.Period->select(start < end)->notEmpty()
-<br/>+<li><span style="color:blue; font-weight:bold">2.20&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.20 &nbsp;&nbsp;</span>'''Fiscal reporting year'''+'''In an instance document reporting a fiscal year, non-numeric facts containing text about any portion of that or a prior year MUST have an @contextRef to an xbrli:context for the reporting period year.'''
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''In an instance document reporting a fiscal year, non-numeric facts containing text about any portion of that or a prior year shall have an @contextRef to an xbrli:context for the reporting period year.'''+
<br/> <br/>
</li> </li>
Line 515: Line 296:
and ends at 24:00:00 of its last day, which is the XBRL 2.1 default for periods. Only the date, not the time part and ends at 24:00:00 of its last day, which is the XBRL 2.1 default for periods. Only the date, not the time part
of the ISO 8601 date-times, should be used in contexts. of the ISO 8601 date-times, should be used in contexts.
-<br/>+<li><span style="color:blue; font-weight:bold">2.21&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.21 &nbsp;&nbsp;</span>'''Fiscal reporting year-to-date'''+'''In an instance document reporting a fiscal year-to-date, the non-numeric facts containing text about any portion of the year-to-date or prior year MUST have an @contextRef to an xbrli:context representing the year-to-date.'''
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''In an instance document reporting a fiscal year-to-date, the non-numeric facts containing text about any portion of the year-to-date or prior year shall have an @contextRef to an xbrli:context representing the year-to-date.'''+
<br/> <br/>
</li> </li>
Line 524: Line 303:
Acquisitions note contains text describing that same acquisition. The 3rd quarter text should be in the context Acquisitions note contains text describing that same acquisition. The 3rd quarter text should be in the context
for the first nine months (that is, the year-to-date). for the first nine months (that is, the year-to-date).
 +<li><span style="color:blue; font-weight:bold">2.22&nbsp;&nbsp;</span>
 +'''In an instance document the periods defined in the contexts SHOULD refer to the same reporting period.'''
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.22 &nbsp;&nbsp;</span>'''Reporting period consistency'''+The dates defined in instant or duration should not exceed the first or the last day of the reporting period in a single instance as required by the regulator.<br/>
-<br/>+<span style="color:green; font-weight:bold">Example: corrections on previous periods MAY be using a different (version of the) taxonomy to prevent possible conflicts with the receiving regulator</span>
-The dates defined in xbrli:instant or xbrli:startDate / xbrli:endDate should not exceed the first or the last day of the reporting period in a single instance as required by the regulator.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that the periods defined in the contexts refer to the same reporting period.'''+
-<br/>+
</li> </li>
- Example: corrections on previous periods may be using a different (version of the) taxonomy to prevent possible  
- conflicts with the receiving regulator 
-  
'''context''' Context '''inv''': '''context''' Context '''inv''':
self.Period.allInstances()->forAll(p1, p2| self.Period.allInstances()->forAll(p1, p2|
p1 = p2 '''implies''' (p1.start = p2.start p1 = p2 '''implies''' (p1.start = p2.start
'''and''' p1.end = p2.end) '''or''' p1.instant = p2.instant) '''and''' p1.end = p2.end) '''or''' p1.instant = p2.instant)
-<br/>+<li><span style="color:blue; font-weight:bold">2.23&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.23 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:context/xbrli:entity/xbrli:segment and xbrli:xbrl/xbrli:context/xbrli:scenario'''+'''xbrli:segment MUST NOT be used.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.4}</span><br/>
-The taxonomy author will assign either the xbrli:segment or xbrli:scenario container node to the dimensional validation. The XBRL specification allows however for any other content that is schema valid to be put in these containers by the reporter. This can disrupt processing of the instance by the regulator.+As xbrli:scenario and xbrli:segment elements are treated as mutually exclusive, using both of them is prohibited.
-For consistency reasons European taxonomy authors use the xbrli:scenario node only.+<br><span style="color:green; font-weight:bold">For consistency reasons everybody uses the xbrli:scenario container.</span><span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-25|Comment-25]]</span>
-<br>+ 
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification allows for both containers to be present once in any xbrli:context. +
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.4</span>: One of xbrli:segment or xbrli:scenario must not appear in any xbrli:context.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.4</span>: The xbrli:scenario must not appear in any xbrli:context.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to be using only a single container node (preference for xbrli:scenario) in the xbrli:context.'''+
-<br/>+
</li> </li>
'''context''' Context '''inv''': '''context''' Context '''inv''':
self.DimensionalContainer.segment->isEmpty() self.DimensionalContainer.segment->isEmpty()
-<br/>+<li><span style="color:blue; font-weight:bold">2.24&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.24 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:context/xbrli:scenario'''+'''If an xbrli:scenario element appears in a context, then its children must be one or more xbrldi:explicitMember and/or xbrldi:typedMember elements.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.6}</span><br/>
The xbrli:scenario element MUST NOT be used for anything other than for explicit or typed members. The xbrli:scenario element MUST NOT be used for anything other than for explicit or typed members.
-<br/>+<span style="color:green; font-weight:bold">Custom reporter XML schema content would create problems with the regulatory system.</span>
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification allows xs:any content. This means that all XML schema content can be stored (not just XBRL Dimensions).+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.5</span>: If an xbrli:segment or xbrli:scenario element appears in a context, then its children must be one or more xbrldi:explicitMember elements.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.5</span>: If an xbrli:segment element appears in a context, then its children must be one or more xbrldi:explicitMember elements.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''If an xbrli:scenario element appears in a xbrli:context, then its required for its children to be one or more xbrldi:explicitMember and/or xbrldi:typedMember elements, and not allowing any reporter custom content.'''+
-<br/>+
</li> </li>
</ul> </ul>
 +<span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-17|Comment-17]]</span>
=== Fact related rules === === Fact related rules ===
<ul> <ul>
-<br/>+<li><span style="color:blue; font-weight:bold">2.25&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.25 &nbsp;&nbsp;</span>'''Duplicate facts'''+'''There MUST NOT be two facts having the same element name, equal contextRef attributes, and if they are present, equal unitRef attributes and xml:lang attributes, respectively.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.11}</span><br/>
An instance document must not have more than one fact having S-Equal element names, equal contextRef attributes, and if they are present V-Equal, unitRef attributes and xml:lang attributes, respectively. An instance document must not have more than one fact having S-Equal element names, equal contextRef attributes, and if they are present V-Equal, unitRef attributes and xml:lang attributes, respectively.
The values of the id attribute and the text content of the element are not relevant to detection of duplicate facts. Other rules forbidding equivalent xbrli:context and xbrli:unit elements ensure that duplicate values of the contextRef and unitRef attributes can be detected without dereferencing. The predicate V-Equal is as defined in the XBRL 2.1 specification. The V-Equal test is sensitive to the underlying data type, so the decimals attribute of ‘-6’ is V-Equal to decimals ‘-06.0’. In unusual cases the same fact may be presented with different levels of detail, such as “123456 Shares with decimals equal to ‘INF’”, and “120000 Shares with decimals equal to ‘-3’”. The values of the id attribute and the text content of the element are not relevant to detection of duplicate facts. Other rules forbidding equivalent xbrli:context and xbrli:unit elements ensure that duplicate values of the contextRef and unitRef attributes can be detected without dereferencing. The predicate V-Equal is as defined in the XBRL 2.1 specification. The V-Equal test is sensitive to the underlying data type, so the decimals attribute of ‘-6’ is V-Equal to decimals ‘-06.0’. In unusual cases the same fact may be presented with different levels of detail, such as “123456 Shares with decimals equal to ‘INF’”, and “120000 Shares with decimals equal to ‘-3’”.
Instead of including both facts in the instance, the instance should contain only the more precise one. Instead of including both facts in the instance, the instance should contain only the more precise one.
-<br/> 
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: Duplicate facts are XML-XBRL syntax valid. However, the semantic meaning may be unclear. 
-<br/> 
-<span style="color:blue; font-weight:bold">GFM 1.2.11</span>: An instance must not have more than one fact having the same element name, equal contextRef attributes and, if they are present, equal unitRef attributes and xml:lang attributes, respectively. 
-<br/> 
-<span style="color:blue; font-weight:bold">EFM 6.5.12</span>: An instance must not have more than one fact having the same element name, equal contextRef attributes and, if they are present, equal unitRef attributes and xml:lang attributes, respectively. 
-<br/> 
-<span style="color:blue; font-weight:bold">FRIS</span>: An instance MUST NOT contain duplicate facts. 
-<br/> 
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to prohibit two facts having the same element name, equal contextRef attributes and, if they are present, equal unitRef and xml:lang attributes, respectively.''' 
-<br/> 
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">2.26&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.26 &nbsp;&nbsp;</span>'''@precision'''+'''@precision MUST NOT be used.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.16}</span><br/>
-The meaning of the @precision can be expressed in @decimals, by stipulating a negative value in the latter. This makes it possible to have two attributes expressing the same semantic information on a fact.+The decimal attribute must be used instead as it holds equivalent information.
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification allows the @precision to be used on numeric facts, by expressing an integer value.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.16</span>: The xbrli:xbrl element must not have any facts with the precision attribute.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.17</span>: The xbrli:xbrl element must not have any facts with the precision attribute.+
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.8.5</span>: An instance monetary fact MUST NOT use @precision.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to be using @decimals as the only means for expressing precision on a fact.'''+
-<br/>+
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">2.27&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.27 &nbsp;&nbsp;</span>'''@decimals'''+'''@decimals value MUST NOT cause non-zero digits in the fact value to be changed to zero.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.26}</span><br/>
-The @decimals is about the accuracy of the fact value. A positive value in @decimals would mean that some of the digits in the value are not precise which could influence calculations required by the regulator.+Instance documents must not contain truncations or roundings that result in reductions of the number of significant figures.
-A negative value in @decimals would mean that the reported fact value is actually a larger value (thousands, millions etc.), which can also signifacantly influence the calculations required by the regulator.+
-To enable calculations to be performed on instance values for validation purposes no truncations or roundings should appear in the instance.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification allows the @decimals to be used on numeric facts, by expressing an integer value.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.26</span>: Non significant digits for values for numeric facts MUST be equal to '0'.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.6.32</span>: The value of the decimals attribute of a fact must correspond to the accuracy of the corresponding amount as reported in the official HTLM/ASCII document.+
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.8.4</span>: An instance monetary fact MUST use @decimals with 'INF' or 0.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have the @decimals value not causing non-zero digits in the fact to be changed to zero.'''+
-<br/>+
-<br/>+
If the decimals attribute of a numeric fact is not equal to “INF”, then the value is interpreted as if certain digits were zero. If the decimals attribute of a numeric fact is not equal to “INF”, then the value is interpreted as if certain digits were zero.
Example: The table below illustrates correct and incorrect use: Example: The table below illustrates correct and incorrect use:
Line 649: Line 372:
This rule is valuable when XBRL Formulas are used to evaluate the correctness of the data. This rule is valuable when XBRL Formulas are used to evaluate the correctness of the data.
</li> </li>
 +<li><span style="color:blue; font-weight:bold">2.28&nbsp;&nbsp;</span>
 +'''The @decimals value MUST correspond to the accuracy of the corresponding amount as reported in the regulatory filing.'''
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.28 &nbsp;&nbsp;</span>'''@decimals accuracy'''+The decimals attribute influences how numbers are interpreted in XBRL and any value for the decimals attribute other than the value INF implies rounding or truncation. Use the following table to select the correct value of the decimals attribute for a fact so that it corresponds to the value as presented (most often rounded) in instance documents.
-<br/>+
-The decimals attribute is not a scale factor. The decimals attribute is not a formatting code; it does not indicate that the digits in the instance must subsequently be presented to a user in any particular way.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.6.31</span>: The content of a numeric fact never has a scale factor.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have the @decimals value correspond to the accuracy of the corresponding amount as reported in the regulatory filing.'''+
-<br/>+
-<br/>+
-The decimals attribute influences how numbers are interpreted in XBRL and any value for the decimals attribute other than the value 'INF' implies rounding or truncation. Use the following table to select the correct value of the decimals attribute for a fact so that it corresponds to the value as presented (most often rounded) in instance documents.+
{| border="1" cellpadding="2" cellspacing="0" {| border="1" cellpadding="2" cellspacing="0"
Line 680: Line 396:
|} |}
 +<br/>
Examples: The table below illustrates correct use. Examples: The table below illustrates correct use.
Line 696: Line 413:
|} |}
 +The decimals attribute is not a scale factor. The decimals attribute is not a formatting code; it does not indicate that the digits in the instance must subsequently be presented to a user in any particular way.
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">2.29&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.29 &nbsp;&nbsp;</span>'''@xsi:nil'''+<span style="color:green; font-weight:bold">'''The @xsi:nil="true" MUST be used if the concept is to be reported but cannot hold the value zero or any reportable value.'''</span>
-<br/>+
-There is a difference in reporting facts with the value zero, empty or xsi:nil='true'. It is up to the regulator to determine the meaning of the different situations.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XML specification allows for any fact to be reported as xsi:nil='true'.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 2.2.6</span>: The xsi:nil='true' attribute must be used only to convey a value that is different from both 'zero' and different from not reporting the fact at all, or to identify a fact detailed only by a link:footnote.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.6.15</span>: The xsi:nil='true' attribute must be used only to convey a value that is different from both 'zero' and different from not reporting the fact at all, or to identify a fact detailed only by a link:footnote.+
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.1.5</span>: An instance MUST NOT contain any @xsi:nil.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to use the @xsi:nil="true" if the concept is to be reported but cannot hold the value zero or any reportable value.'''+
-<br/>+
<br/> <br/>
Data related to white cells could be reported with the according value, as zero or as unknown. The table below shows the different possible solutions: Data related to white cells could be reported with the according value, as zero or as unknown. The table below shows the different possible solutions:
Line 728: Line 433:
|} |}
</li> </li>
-<br/>+<li><span style="color:blue; font-weight:bold">2.30&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.30 &nbsp;&nbsp;</span>'''@decimal accuracy'''+<span style="color:green; font-weight:bold">'''Numeric fact MUST be accurate to the @decimal value.'''</span>
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>:+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM</span>:+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM</span>:+
-<br/>+
-<span style="color:blue; font-weight:bold">SBR</span>:+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have numeric facts to be accurate to the @decimal value.'''+
<br/> <br/>
</li> </li>
Line 748: Line 443:
000.2000. 000.2000.
The value “20%” must not appear in a numeric fact as “20”, “20/100”, “20%” or any variation of the integer “20”. The value “20%” must not appear in a numeric fact as “20”, “20/100”, “20%” or any variation of the integer “20”.
-<br/>+<li><span style="color:blue; font-weight:bold">2.31&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.31 &nbsp;&nbsp;</span>'''@xml:lang'''+'''For non numeric facts: The language used MUST be clearly identified.'''
<br/> <br/>
The language used on string based facts needs to be identified. This can be done by declaring the @xml:lang on the xbrli:xbrl element just once, or on every string based fact individually. No rules have been set for regulators allowing multiple language reportings (choices are to support all languages in a single instance or to require multiple, language based, instances). The language used on string based facts needs to be identified. This can be done by declaring the @xml:lang on the xbrli:xbrl element just once, or on every string based fact individually. No rules have been set for regulators allowing multiple language reportings (choices are to support all languages in a single instance or to require multiple, language based, instances).
-The preferred option is to have multiple language in a single instance.+<span style="color:green; font-weight:bold">The preferred option is to have multiple language in a single instance.</span>
-<br/>+<span style="background-color:yellow">[[Talk:European_Filing_Rules#Comment-24|Comment-24]]</span>
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XML specification allows the @xml:lang on every fact. It's content is not restricted (to, for example ISO639).+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.12</span>: The default language of the xml:lang attribute on non-numeric facts and on link:footnote is equal to the default language.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.13</span>: The default language of the xml:lang attribute on non-numeric facts and on link:footnote is 'en-US'. +
-<br/>+
-<span style="color:blue; font-weight:bold">SBR 2.1.1</span>: An instance MUST contain xbrli:xbrl/@xml:lang.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have clear policy to define the language for non numeric facts.'''+
-<br/>+
</li> </li>
 +<li><span style="color:blue; font-weight:bold">2.32&nbsp;&nbsp;</span>
 +'''@id on individual facts SHOULD NOT be used.'''
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.32 &nbsp;&nbsp;</span>'''@id on individual facts'''+The @id on individual facts is meant to connect texts in the form of a footnote, which is prohibited.
-<br/>+
-The @id on individual facts is meant to uniquely reference the fact from other XML constructs. E.g. a footnote.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: Their is no length restriction for the @id. An @id uniquely identifies an element in an XML document. The data type for @id is xs:NCName.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended not to use any @id on facts.'''+
-<br/>+
</li> </li>
</ul> </ul>
Line 779: Line 459:
=== Unit related rules === === Unit related rules ===
<ul> <ul>
-<br/>+<li><span style="color:blue; font-weight:bold">2.33&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.33 &nbsp;&nbsp;</span>'''Duplicates of xbrli:xbrl/xbrli:unit'''+'''xbrli:xbrl/xbrli:unit MUST NOT have duplicates.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.10}</span><br/>
-Units are equivalent if they have equivalent measures or equivalent numerator and denominator. Measures are equivalent if their contents are equivalent QNames. Numerators and Denominators are equivalent if they have a set of equivalent measures.+Element xbrli:xbrl must not have equivalent child xbrli:unit elements. Units are equivalent if they have equivalent measures or equivalent numerator and denominator. Measures are equivalent if their contents are equivalent QNames. Numerators and Denominators are equivalent if they have a set of equivalent measures.
-Duplicated units do not express extra semantics and potentially disturb comparison of facts that point to any of the duplicated occurences.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: XML allows duplicate nodes. No processing or semantic relevancy to the order found are being made. XBRL has described multiple types of 'equalities', these are described in the XBRL 2.1 specification, but the ones appearing in instances are not prohibited.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.10</span>: Element xbrli:xbrl must not have duplicate child xbrli:unit elements.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.11</span>: Element xbrli:xbrl must not have duplicate child xbrli:unit elements.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.7.1</span>: An instance MUST NOT contain s-equal units.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required not having duplicate units in an XBRL instance.'''+
-<br/>+
</li> </li>
'''context''' Unit '''inv''': '''context''' Unit '''inv''':
Line 800: Line 468:
u1 <> u2 '''implies''' (u1.id <> u2.id u1 <> u2 '''implies''' (u1.id <> u2.id
'''and''' u1.measure->asOrderedSet() <> u2.measure->asOrderedSet()) '''and''' u1.measure->asOrderedSet() <> u2.measure->asOrderedSet())
-<br/>+<li><span style="color:blue; font-weight:bold">2.34&nbsp;&nbsp;</span>
-<li><span style="color:blue; font-weight:bold">2.34 &nbsp;&nbsp;</span>'''Unused xbrli:xbrl/xbrli:unit'''+'''There MUST NOT be unused xbrli:xbrl/xbrli:unit.'''
-<br/>+<span style="color:green; font-weight:bold">{GFM 1.2.27}</span><br/>
-Unused units (units which are not referred to by facts) clutter the instance and add no value to either regulator or reporter.+Unused units (units which are not referred to by facts) clutter the instance and add no value.
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: XML and XBRL do not prohibit the existence of non referenced unit nodes.+
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.27</span>: An instance document must not contain unused units.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM</span>: Every xbrli:unit element must appear in at least one unitRef attribute in the same instance.+
-<br/>+
-<span style="color:blue; font-weight:bold">FRIS 2.7.2</span>: An instance MUST NOT contain unused units.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to prevent unused xbrli:unit nodes to be present in the instance.'''+
-<br/>+
</li> </li>
'''context''' Unit '''inv''': '''context''' Unit '''inv''':
self.Fact.allInstances()->notEmpty() self.Fact.allInstances()->notEmpty()
 +
 +<li><span style="color:blue; font-weight:bold">2.35&nbsp;&nbsp;</span>
 +'''xbrli:xbrl/xbrli:unit declarations SHOULD adhere to XBRL international unit registry content.'''
 +<span style="color:green; font-weight:bold">{GFM 1.2.29}</span><br/>
 +XBRL 2.1 already enforces the requirement that a fact of type xbrli:monetaryItemType must have a unitRef whose xbrli:measure is an ISO standard currency. A standard numeric data type registry is similar but broader: it has a schema with numeric type declarations, and each numeric data type is associated with consistent unit declaration measures, numerators and denominators.
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.35 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:unit/* content'''+http://www.xbrl.org/utr/utr.xml
-<br/>+
-XII has released a standard numeric data type registry: it has a schema with numeric type declarations, and each numeric data type is associated with consistent unit declaration measures, numerators and denominators. Use of this registry that contains all the usual units eases implemenation in software and simplifies validation. +
-Link: [http://www.xbrl.org/utr/utr.xml XII UTR]+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: The XBRL specification enforces that a fact of type xbrli:monetaryItemType must have a xbrli:unitRef whose xbrli:measure QName is an ISO standard currency. +
-<br/>+
-<span style="color:blue; font-weight:bold">GFM 1.2.29</span>: If a standard numeric data type regisry namespace is declared in the DTS of an instance, then the value of each 'unitRef' attribute on each fact of a type in that registry must refer to a unit declaration consistent with the data type of that fact, where consistency is defined by that registry.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.5.35</span>: If element 'UTR' in a standard namespace is declared in the DTS of an instance, then the value of each 'unitRef' attribute on each fact of a type in that registry must refer to a unit declaration consistent with the data type of that fact, where consistency is defined by that registry.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended to have the xbrli:unit children referring the XBRL International Unit Type Registry (UTR).'''+
<br/> <br/>
</li> </li>
 +<li><span style="color:blue; font-weight:bold">2.36&nbsp;&nbsp;</span>
 +<span style="color:green; font-weight:bold">'''xbrli:xbrl/xbrli:unit MUST represent currencies to their physical value.'''</span>
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.36 &nbsp;&nbsp;</span>'''xbrli:xbrl/xbrli:unit/xbrli:measure'''+To express amounts in US Dollars, use only xbrli:unit with one xbrli:measure element whose content is the QName iso4217:USD. Do not define units such as “thousands of USD”, “millions of GBP”, or “pence”.
-<br/>+
-To express amounts in any currency, it is possible to use only xbrli:unit/xbrli:measure element whose content is the QName of (e.g.) iso4217:USD. But it is also possible to use xbrli:unit/xbrli:divide/xbrli:numerator with the iso4217 value and a xbrli:denoniator of '1000' or '1000000', which would introduce precision through the unit on a numeric fact. Precision is already covered by the @decimals on a fact. There should not be two methods of expressing the same.+
-<br/>+
-<span style="color:blue; font-weight:bold">XML-XBRL</span>: No restrictions are posed by the XML-XBRL specifications.+
-<br/>+
-<span style="color:blue; font-weight:bold">EFM 6.6.34</span>: Do not define or use units that imply a scale factor on a currency.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required to have units representing currencies, to represent the actual physical value of these currencies.'''+
<br/> <br/>
</li> </li>
 +<li><span style="color:blue; font-weight:bold">2.37&nbsp;&nbsp;</span>
 +'''An instance document SHOULD contain only a single currency unit.'''
<br/> <br/>
-<li><span style="color:blue; font-weight:bold">2.37 &nbsp;&nbsp;</span>'''Currencies'''+<span>Amounts that a reported should refer to only to one xbrl:unit with a xbrli:measure that content is a QName starting with iso4217. </span>
-<br/>+
-Amounts that a reported should refer to only to one xbrl:unit with a xbrli:measure that content is a QName starting with iso4217.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is recommended that an instance express its monetary values through a single currency unit.'''+
-<br/>+
</li> </li>
'''context''' Instance '''inv''': '''context''' Instance '''inv''':
self.Unit->select(measure.substring(1, 7) = #iso4217)->size()=1 self.Unit->select(measure.substring(1, 7) = #iso4217)->size()=1
 +
</ul> </ul>
=== Footnote related rules === === Footnote related rules ===
<ul> <ul>
-<li><span style="color:blue; font-weight:bold">2.38 &nbsp;&nbsp;</span>'''Footnotes'''+<li><span style="color:blue; font-weight:bold">2.38&nbsp;&nbsp;</span>
-<br/>+<span style="color:green; font-weight:bold">'''Information eligable for footnotes MUST be included in the appropriate concepts only.'''</span>
-The tables of the European reporting frameworks consist of white, gray and crisscrossed cells. White cells can be reported if data is available and can be retrieved from the database of the reporting entity. Gray cells could be reported but they are not mandatory because the level of detail is excluded from the reporting. Crisscrossed cells make no sense from an economic point of view. Additional information to white cells outsourced in footnotes cannot be handled by regulators, all information is captured in datapoints that are reflected in concepts.+
-<br/>+
-<span style="color:blue; font-weight:bold">CWA Advice</span>: '''It is required that information in the instance is included in the appropriate concepts only.'''+
<br/> <br/>
 +The tables of the European reporting frameworks consist of white, gray and crisscrossed cells. White cells can be reported if data is available and can be retrieved from the database of the reporting entity. Gray cells could be reported but they are not mandatory because the level of detail is excluded from the reporting. Crisscrossed cells make no sense from an economic point of view. Additional information to white cells outsourced in footnotes are not allowed.
</li> </li>
</ul> </ul>
Line 873: Line 514:
* [http://www.sec.gov/info/edgar/edmanuals.htm EDGAR Filer Manual] ''U.S. Securities and Exchange Commission'' * [http://www.sec.gov/info/edgar/edmanuals.htm EDGAR Filer Manual] ''U.S. Securities and Exchange Commission''
* [http://www.ifrs.org/XBRL/Resources/Pages/IFRS-Taxonomy-Guide.aspx IFRS Taxonomy Guide] * [http://www.ifrs.org/XBRL/Resources/Pages/IFRS-Taxonomy-Guide.aspx IFRS Taxonomy Guide]
-* [http://www.xbrl.org/technical/guidance/FRIS-PWD-2004-11-14.htm XBRL Internation FRIS] ''Financial Reporting Instance Standards 1.0''+ 
-* [http://www.sbr-nl.nl/fileadmin/SBR/documenten/NT_2013/definitief_03122012/NL-FRIS_NT2013_20121210.pdf SBR FRIS rules 2013]+
* [https://eiopa.europa.eu/publications/eu-wide-reporting-formats/index.html EIOPA: EU-wide Reporting Formats] * [https://eiopa.europa.eu/publications/eu-wide-reporting-formats/index.html EIOPA: EU-wide Reporting Formats]

Revision as of 06:13, 8 May 2013

CEN Workshop Agreement

Status: Working Group Working Draft

CEN WS XBRL Experts: Thierry Declerck (DFKI), Roland Hommes (Rhocon), Katrin Heinze (Deutsche Bundesbank)

Editing rules

Editorial comments should be highlighted as follows: A comment

Text or rules in discussion (white): Some text

Text or rules already aligned (green): Some text

Text or rules to be deleted (red): Some text

Text to be delivered (blue): Some text

Contents

Foreword

Some text

Introduction

The eXtensible Business Reporting Language (XBRL) specification provides a high degree of flexibility in the creation of XBRL instance documents. The following set of rules are intended to recommend best practices on the freedom of choice for the benefit of clear guidance on preparation and validation of instance documents and an increase of interoperability between computer applications. They also facilitate the analysis and comparison of instance documents for preparers as well as receivers of XBRL in the reporting process.

The filing rules represent a collection of recommendations to be seen as advisable to be implemented in the European supervisory reporting process. The rules are recommended to be adopted by national supervisors for other reporting purposes when they do not contradict their needs, i.e. footnotes are sometimes necessary to explain the content of reported fact. The listed filing rules are influenced by the European Taxonomy Architecture in cases where the instance creation is affected.

The purpose of these filing rules is minimize the reporting burden for reporting entities in Europe notwithstanding amendments to these rules would be optionally prescribed by one or more regulators.

Notwhitstanding the only authoritative restrictions are respectivelly the XBRL specifications and the regulatory instructions, the following set of rules helps to avoid unnecesary complications by adopting well stablished best practices.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This guidance is in the form of notes in association with the pertaining requirements clause and uses the terms “MUST” (strong recommendation), “SHOULD” or "RECOMMENDED" (recommendation) and “MAY” (possibility). Organizations wishing to implement this CWA (CEN Workshop Agreement) would be expected to consider all recommendations where the terms "MUST", “SHOULD” and "RECOMMENDED" are used.

Objective

The primary objective is interoperability, by harmonization and guidance on the rules of XBRL taxonomy creation process carried out by regulators, supervisory authorities, voluntary suplly chains and others.

The secondary objective is facilitate adoption, by maintaining as simple as possible the technological requirements when creating XBRL instance documents.

The fundamental use case that guides the following set of rules is the submission, by a reporting entity, of its regulatory filings, and the consumption of those regulatory filings by several reporting applications.

The following set of rules provides guidance on the preparation and validation of instance documents in XBRL format.

The rules in this document also aim to facilitate the analysis and comparison of reporting data as well as the interoperability of computer applications.

Target Audience

This document is intended for a technical audience and assumes that the reader has a working knowledge of the XBRL 2.1 and the XBRL Dimensions 1.0 Specifications and has a basic understanding of XML, Namespaces, and XML Schema.

To readers with XML knowledge, many of the guidelines in this document will be familiar however, other rules originate from features that are XBRL-specific and therefore the reasoning behind these rules may be less obvious. Where appropriate, the rules are accompanied by a brief explanation.

To ease understanding for software developers implementing these rules in their reporting system, an UML model has been created to show the relationships between the different XBRL objects mentioned in this document.

Relationship to Other Work

The guidelines in this document pertain to XBRL filings. Parts of this document reiterate for expository clarity certain syntactic and semantic restrictions imposed by XBRL, but this document does not modify XBRL. In the event of any conflicts between this document and XBRL, XBRL prevails. This document does place additional restrictions beyond those prescribed by XBRL.

Scope

The rules in this document have been created for regulatory filings in the context of European supervisory reporting. In this document, “regulatory filings” encompasses European reporting standards that are published by an European supervisory authority and accompanied by an XBRL taxonomy as well as extensions on these taxonomies provided by national supervisors.

Normative references

Terms and definitions

Applicable taxonomy 
An XBRL taxonomy recognised to use as a base for filings in a given filing system.
Data point 
A data point is an information component that is defined by a supervisory authority to be sent in an instance document. In XBRL a data point is represented by a fact, its value and related dimensional combinations.
Dimension 
A dimension is an xs:element in the substitutionGroup of xbrldt:dimensionItem; it relates to the ability to express multidimensional information;
Entrypoint 
A schema or linkbase in the applicable taxonomy that represents the filing requirements and gets mentioned in the instance by the reporter.
Fact 
A fact is an occurrence in an instance document of an element with a mandatory contextRef attribute and optional attributes like unitRef, xml:lang or xsi:nil.
Filer 
A reporting entity.
Filing 
A filing is the fundamental unit of information that is transmitted to a filing system for receipt, validation and acceptance. It is the conveyance of an XBRL instance document or series of XBRL instance documents.
Filing system 
A system in which XBRL instance documents are filed, received, analysed and redistributed.
Footnote 
A footnote is used to associate text annotations with particular facts in an XBRL instance document.
Instance document 
An instance document is an XBRL file carrying facts. An instance document originating with a filer can only be sent as part of a filing. A filing comprises of one or more instance documents.
Linkbase 
A linkbase is an XML file according to the XBRL 2.1 specification, containing relationships between concepts, resources and concepts and resources providing labels and references. There are different kinds of linkbases. One of them is the formula linkbase containing business rules in the syntax as prescribed by the XBRL Formula Specification.
Publisher of the schema 
Organisation responsible for publishing a given XBRL taxonomy.
Reporting entity 
A reporting entity is a institution or company with an obligation to prepare supervisory reports for national or European supervisory authorities.
Taxonomy
In the XBRL context, an electronic dictionary of business reporting elements relevant for reporting business data. A taxonomy is composed of an XML Schema and one or more linkbases directly referenced by that schema. ; Taxonomy creator : see Publisher of the schema
XBRL specific terms like context, unit, period, entity, s-equal, v-equal see XBRL 2.1

Symbols and abbreviations

UML 
Unified Modelling Language
W3C 
World Wide Web Consortium
XBRL 
eXtensible Business Reporting Language
XML 
eXtensible Markup Language

Rules

Filing syntax rules

  • 1.01    The file name of an instance document SHOULD follow the rules of the national filing system.
    There is no prescribed way of handling instance document file names. Different naming conventions exist around the world, mostly conveying some kind of meaning about the sender, the reported filing or reported period.
  • 1.02   Reporting entities SHOULD use one of the taxonomies as specified in the filing system as the applicable taxonomy. {GFM 1.1.5}
    A listing of all taxonomy files respective modules recognised in the filing system should be provided on a web location.
  • 1.03   The encoding of all instance documents SHOULD be "UTF-8". {GFM 1.1.8}
    Several standards exist on the representation and handling of text. Some of the standards like ISO-8859-1 are widely used in various countries but the standards itself are largely incompatible with each other. UTF-8 is the preferred and most used encoding in HTML documents and therefore defined as Best Practice. It is necessary to specify the encoding attribute in the prologue of an instance document.
  • context xmlDocument inv: 
        self.encoding = 'UTF-8'
    
  • 1.04   Reporting entities SHOULD use only one of entrypoint schemas as specified in the applicable taxonomy.
    It is recommended to refer to a single entrypoint in an instance document and therefore include only one link:schemaRef element. This is because the data point modelled taxonomies MAY contain multiple tables but these are not treated as an entrypoint. Only the whole of the taxonomy has a single entrypoint for all tables. Through the 'FilingIndicators' it is communicated which tables are communicated in the instance.
  • 1.05   Instance documents MUST be XBRL 2.1 and XBRL Dimensions 1.0 valid.
    Each instance document in the filing is tested separately for XBRL 2.1 validity. In order to increase the likelihood that instance documents pass validation, filers are encouraged to validate their compliance with the XBRL 2.1 Specification prior to submission.
  • context Instance::isXBRLValid() : Boolean 
        post: result = true
    
  • 1.06   The instance documents SHOULD be valid with regards to XBRL Formula as defined in the applicable taxonomy.
    Any formula linkbase discovered by the XBRL software from opening the entrypoint can contain tests on the quality of the reported data. The tests that report an error on these data SHOULD be corrected. There MAY be tests that produce only warnings. Solving these warnings depends on the message content and the filer perspective on them.
  • context Instance::isFormulaValid() : Boolean 
        post: result = true
    

    Comment-14

  • 1.07   Reports MUST contain only concepts created by the taxonomy author.
    XBRL Taxonomies can be extended by anybody with the proper technical knowledge. Filings to European Regulatory Authorities are 'closed form' i.e. all data points allowed by the regulator are in the taxonomy. There can be no extension of the taxonomy by reporters to report more data points to the regulator.
  • context Taxonomy inv:
        self.owner = ‚European Banking Authority’
        or self.owner = ‚European Insurance and Occupational Pensions Authority’
    
  • 1.08   Reporters SHOULD always send the full applicable dataset for an entrypoint schema in an instance document.
    In case of corrections it is recommended not to send partial data with just the corrected facts. Non-complete submissions could lead to invalid instance documents and might raise conflicts with already processed data in the reporting system of the receiver.

Comment-12

Instance syntax rules

  • 2.01   Attribute @xml:base SHOULD NOT appear in any instance document. {GFM 1.1.7}
    XML processors interpret this attribute differently, so it should not be used.
  • context xmlDocument inv: 
       self.element->select(xml:base)->isEmpty()
    
  • 2.02   link:schemaRef MUST contain the full URL as published on the internet
    The version of any report is represented in folder names, not in URI namespaces. To correctly interpret the reported facts the proper entrypoint schema and its taxonomy must be present in the instance by including the full path (including the folder with the version indicator in it) in the link:schemaRef element.
  • 2.03   xmlversion in the instance MUST be 1.0
    Although version 1.1 exists, XBRL instances MUST be based on version 1.0.
  • context xmlDocument inv: 
       self.version = '1.0'
    
  • 2.04   Declared namespace prefixes SHOULD be used
    Declaring unused namespaces is uncalled for and clutters the instance document.
  • 2.05   Declared namespace prefixes SHOULD mirror the namespace prefixes as defined by schema author(s) {GFM 1.2.28}
    The W3C, XBRL International and the taxonomy author all assign namespace prefixes to their schema's. Human interpretation of the instance could be confused when these namespace prefixes are not followed in the instance.
  • 2.06   There MUST be only one link:schemaRef in an instance
    Taxonomy authors will make sure that a single entrypoint schema needs to be referred to in the instance. This entrypoint will refer all required data points.
  • context Instance inv: 
       self.SchemaReference->size() = 1
    
  • 2.07   There MUST be only link:schemaRef nodes to refer to external files
    Entrypoints will be defined by means of a schema, and considering footnote linkbases are not allowed, there is no use for link:linkbaseRef.
  • 2.08   The instance SHOULD only contain contexts, units, schemaRefs and facts.
    Verbose comments inside the instance that do not get reported as a fact will be ignored by the regulator. These comments clutter the instance and have no use to the regulator.

Context related rules

Comment-23

  • 2.10   It SHOULD be avoided to have duplicates of xbrli:xbrl and xbrli:context elements. {GFM 1.2.7}
    An instance document must not contain equivalent xbrli:context elements.The two sub-elements of xbrl:context xbrli:segment and xbrli:scenario elements are tested for equality of their children without regard to order. Contexts are defined to be equivalent if they have S-equal identifiers, equal dateUnion values for startDate, endDate and instant (respectively), and segment or scenario element children with equal QNames for each explicit dimension.
  • context Context inv: 
       self.allInstances()->forAll(c1, c2|
       c1 <> c2 implies (c1.DimensionalContainer.scenario <> c2.DimensionalContainer.scenario 
       and c1.Identifier.value <> c2.Identifier.value 
       and c1.Identifier.scheme <> c2.Identifier.scheme 
       and(c1.Period.start <> c2.Period.start and c1.Period.end <> c2.Period.end or c1.Period.instant <> c2.Period.instant)
    
  • 2.11   Id attributes SHOULD represent non semantic relevant content.
    Even though there is no limitation on the length of an id attribute it is recommended to keep it as short as possible. Id attributes should also be abstract. Id attributes are used for XML internal pointers only.
  • 2.12   There MUST NOT be unused xbrli:context. {GFM 1.2.8}
    Unused contexts (contexts which are not referred to by facts) clutter the instance and add no value.
  • context Context inv:
       self.Fact.allInstances()->notEmpty()
    
  • 2.13   xbrli:identifier/@scheme MUST follow the pattern recognised in the filing system. {GFM 1.2.1}
    It is recommended to use a proprietary national id code with the scheme refering to the corresponding national central bank.
  •  Example: <xbrli:identifier scheme="http://www.kredittilsynet.no">NO12345678</xbrli:identifier>
    
    let schemeUrl : String = ‘http://www.kredittilsynet.no’ -- URL to be replaced
    context Context inv:
       self.Identifier.allInstances()->forAll(scheme = schemeURL)
    
  • 2.14   xbrli:identifier MUST have a number or identifier recognised in the filing system as its content. {GFM 1.2.2}
    See explanation on rule 2.13
  • 2.15   All xbrli:identifier content MUST be identical. {GFM 1.2.3}
    There can only be one reporter of an instance. Even if the content of the instance deals with a group of companies, there is only one entity reporting the instance to the regulator.
  • context Context inv: 
       self.Identifier.allInstances()->forAll(i1, i2|
       i1 = i2 implies i1.value = i2.value)
    
  • 2.16   All xbrli:identifier/@scheme content MUST be identical.
    The scheme attribute MUST correspond to the identifier of the reporting entity and there can only be one scheme defined for the reporting entity in an instance document.
  • context Context inv: 
       self.Identifier.allInstances()->forAll(i1, i2|
       i1 = i2 implies i1.scheme = i2.scheme)
    
  • 2.17   All xbrli:xbrl/xbrli:context/xbrli:period date elements MUST have ccyy-mm-dd format. {GFM 1.2.25}
    The XBRL specification of this element has made it possible to enter a date or a dateTime. European regulators only allow dates.
  • 2.18   xbrli:xbrl/xbrli:context/xbrli:period/xbrli:forever MUST NOT exist. {GFM 1.2.30}
    The extreme version of duration is 'forever'. The XBRL specification has created this to solve problems with dates starting 'at the beginning' and ending 'never'. E.g. the name of the filer has in general no end date. The regulator is only interested in type of data for the reported time segment that has a defined starting and ending date.
  • context Context inv: 
       self.Period.forever->isEmpty()
    
  • 2.19   xbrli:startDate and xbrli:endDate in the same context MUST NOT have the same date. {GFM 1.2.9}
    Note that XBRL 2.1 interprets a date used as a context start date as “midnight at the beginning of” that day. A date used as an instant or endDate in a context means “midnight at the end of” that day. Actually this rule prohibits 24 hour reporting periods. See EFM V22 rule 6.5.9
  •  Example: a company reporting at a May 31st, 2009 fiscal year-end will have contexts whose end date-time is 
     midnight at the end of 2008-05-31 (the prior fiscal year) and contexts whose start date-times are midnight at the 
     beginning of 2008-06-01 (the current fiscal year). It will not have any contexts with start date-time of midnight 
     at the beginning of 2008-05-31, and no contexts with end date-time of midnight at the end of 2008-06-01.
    context Context inv: 
       self.Period->select(start < end)->notEmpty()
    
  • 2.20   In an instance document reporting a fiscal year, non-numeric facts containing text about any portion of that or a prior year MUST have an @contextRef to an xbrli:context for the reporting period year.
  •  Example: in a fiscal year 2009 report a company describes litigation settled in fiscal year 2007. Nevertheless, 
     the disclosure text should be in a context for fiscal 2009. A reporting period begins at 00:00:00 of its first day 
     and ends at 24:00:00 of its last day, which is the XBRL 2.1 default for periods. Only the date, not the time part 
     of the ISO 8601 date-times, should be used in contexts.
    
  • 2.21   In an instance document reporting a fiscal year-to-date, the non-numeric facts containing text about any portion of the year-to-date or prior year MUST have an @contextRef to an xbrli:context representing the year-to-date.
  •  Example: a company completes an acquisition in its second fiscal quarter. In its 3rd quarter fiscal report, the 
     Acquisitions note contains text describing that same acquisition. The 3rd quarter text should be in the context 
     for the first nine months (that is, the year-to-date).
    
  • 2.22   In an instance document the periods defined in the contexts SHOULD refer to the same reporting period.
    The dates defined in instant or duration should not exceed the first or the last day of the reporting period in a single instance as required by the regulator.
    Example: corrections on previous periods MAY be using a different (version of the) taxonomy to prevent possible conflicts with the receiving regulator
  • context Context inv: 
       self.Period.allInstances()->forAll(p1, p2|
       p1 = p2 implies (p1.start = p2.start 
       and p1.end = p2.end) or p1.instant = p2.instant) 
    
  • 2.23   xbrli:segment MUST NOT be used. {GFM 1.2.4}
    As xbrli:scenario and xbrli:segment elements are treated as mutually exclusive, using both of them is prohibited.
    For consistency reasons everybody uses the xbrli:scenario container.Comment-25
  • context Context inv: 
       self.DimensionalContainer.segment->isEmpty()
    
  • 2.24   If an xbrli:scenario element appears in a context, then its children must be one or more xbrldi:explicitMember and/or xbrldi:typedMember elements. {GFM 1.2.6}
    The xbrli:scenario element MUST NOT be used for anything other than for explicit or typed members. Custom reporter XML schema content would create problems with the regulatory system.

Comment-17

Fact related rules

  • 2.25   There MUST NOT be two facts having the same element name, equal contextRef attributes, and if they are present, equal unitRef attributes and xml:lang attributes, respectively. {GFM 1.2.11}
    An instance document must not have more than one fact having S-Equal element names, equal contextRef attributes, and if they are present V-Equal, unitRef attributes and xml:lang attributes, respectively. The values of the id attribute and the text content of the element are not relevant to detection of duplicate facts. Other rules forbidding equivalent xbrli:context and xbrli:unit elements ensure that duplicate values of the contextRef and unitRef attributes can be detected without dereferencing. The predicate V-Equal is as defined in the XBRL 2.1 specification. The V-Equal test is sensitive to the underlying data type, so the decimals attribute of ‘-6’ is V-Equal to decimals ‘-06.0’. In unusual cases the same fact may be presented with different levels of detail, such as “123456 Shares with decimals equal to ‘INF’”, and “120000 Shares with decimals equal to ‘-3’”. Instead of including both facts in the instance, the instance should contain only the more precise one.
  • 2.26   @precision MUST NOT be used. {GFM 1.2.16}
    The decimal attribute must be used instead as it holds equivalent information.
  • 2.27   @decimals value MUST NOT cause non-zero digits in the fact value to be changed to zero. {GFM 1.2.26}
    Instance documents must not contain truncations or roundings that result in reductions of the number of significant figures. If the decimals attribute of a numeric fact is not equal to “INF”, then the value is interpreted as if certain digits were zero. Example: The table below illustrates correct and incorrect use:
    Fact text Decimals value Interpreted value Result
    -2345.45 INF -2,345.45  
    -2345.45 2 -2,345.45  
    -2345.45 0 -2,345.00 Error
    -2345.45 -2 -2,300.00 Error
    -2345.45 -3 -2,000.00 Error
    -2345.45 -6 0000.00 Error
     This rule is valuable when XBRL Formulas are used to evaluate the correctness of the data.
    
  • 2.28   The @decimals value MUST correspond to the accuracy of the corresponding amount as reported in the regulatory filing.
    The decimals attribute influences how numbers are interpreted in XBRL and any value for the decimals attribute other than the value INF implies rounding or truncation. Use the following table to select the correct value of the decimals attribute for a fact so that it corresponds to the value as presented (most often rounded) in instance documents.
    Accuracy of the amount Value of decimals attribute
    Exact monetary, percentage, basis point or any other amount INF
    Rounded to billions -9
    Rounded to millions -6
    Rounded to thousands -3
    Rounded to units 0
    Rounded to cents 2
    Rounded to a whole percentage 4


     Examples: The table below illustrates correct use.
    
    Fact Value Value of decimals attribute
    A percentage of (exactly) 46% .46 INF
    A (rounded) profit margin of 9.3% .093 3
    A (rounded) amount “in thousands” of 100 100000 -3
    A (rounded) amount “in thousands” of 100 100200 -2

    The decimals attribute is not a scale factor. The decimals attribute is not a formatting code; it does not indicate that the digits in the instance must subsequently be presented to a user in any particular way.

  • 2.29   The @xsi:nil="true" MUST be used if the concept is to be reported but cannot hold the value zero or any reportable value.
    Data related to white cells could be reported with the according value, as zero or as unknown. The table below shows the different possible solutions:
    zero value The value of the fact is "0". <p-cm-ca:CapitalRequirements decimal="0" unitRef="EUR" contextRef="ctx_1">0</p-cm-ca:CapitalRequirements>
    nil value The value of the fact is not known or can't be received. <p-cm-ca:CapitalRequirements xsi:nil="true" unitRef="EUR" contextRef="ctx_1"></p-cm-ca:CapitalRequirements>
    not applicable information The value is inapplicable. The fact doesn't appear in the instance.
  • 2.30   Numeric fact MUST be accurate to the @decimal value.
  •  Examples:
     The value “twenty thousand” may appear in a numeric fact as any legal decimal representation of 20,000, such as 
     20000, 20000.0, or 020000. It must not appear as “20”. 
     The value “20%” may appear in a numeric fact as any legal decimal representation of .2, such as 0.2, 0.20, 
     000.2000.
     The value “20%” must not appear in a numeric fact as “20”, “20/100”, “20%” or any variation of the integer “20”.
    
  • 2.31   For non numeric facts: The language used MUST be clearly identified.
    The language used on string based facts needs to be identified. This can be done by declaring the @xml:lang on the xbrli:xbrl element just once, or on every string based fact individually. No rules have been set for regulators allowing multiple language reportings (choices are to support all languages in a single instance or to require multiple, language based, instances). The preferred option is to have multiple language in a single instance. Comment-24
  • 2.32   @id on individual facts SHOULD NOT be used.
    The @id on individual facts is meant to connect texts in the form of a footnote, which is prohibited.

Unit related rules

  • 2.33   xbrli:xbrl/xbrli:unit MUST NOT have duplicates. {GFM 1.2.10}
    Element xbrli:xbrl must not have equivalent child xbrli:unit elements. Units are equivalent if they have equivalent measures or equivalent numerator and denominator. Measures are equivalent if their contents are equivalent QNames. Numerators and Denominators are equivalent if they have a set of equivalent measures.
  • context Unit inv: 
      self.allInstances()->forAll(u1, u2|
      u1 <> u2 implies (u1.id <> u2.id 
      and u1.measure->asOrderedSet() <> u2.measure->asOrderedSet())
    
  • 2.34   There MUST NOT be unused xbrli:xbrl/xbrli:unit. {GFM 1.2.27}
    Unused units (units which are not referred to by facts) clutter the instance and add no value.
  • context Unit inv: 
      self.Fact.allInstances()->notEmpty()
    
  • 2.35   xbrli:xbrl/xbrli:unit declarations SHOULD adhere to XBRL international unit registry content. {GFM 1.2.29}
    XBRL 2.1 already enforces the requirement that a fact of type xbrli:monetaryItemType must have a unitRef whose xbrli:measure is an ISO standard currency. A standard numeric data type registry is similar but broader: it has a schema with numeric type declarations, and each numeric data type is associated with consistent unit declaration measures, numerators and denominators.
    http://www.xbrl.org/utr/utr.xml
  • 2.36   xbrli:xbrl/xbrli:unit MUST represent currencies to their physical value.
    To express amounts in US Dollars, use only xbrli:unit with one xbrli:measure element whose content is the QName iso4217:USD. Do not define units such as “thousands of USD”, “millions of GBP”, or “pence”.
  • 2.37   An instance document SHOULD contain only a single currency unit.
    Amounts that a reported should refer to only to one xbrl:unit with a xbrli:measure that content is a QName starting with iso4217.
  • context Instance inv: 
      self.Unit->select(measure.substring(1, 7) = #iso4217)->size()=1
    

Footnote related rules

  • 2.38   Information eligable for footnotes MUST be included in the appropriate concepts only.
    The tables of the European reporting frameworks consist of white, gray and crisscrossed cells. White cells can be reported if data is available and can be retrieved from the database of the reporting entity. Gray cells could be reported but they are not mandatory because the level of detail is excluded from the reporting. Crisscrossed cells make no sense from an economic point of view. Additional information to white cells outsourced in footnotes are not allowed.

Bibliography


Annex

Image:UML-filing-rules.jpg

Personal tools