Talk:European Filing Rules

From XBRLWiki

Revision as of 14:22, 16 November 2012 (edit) Thierry.Declerck (Talk | contribs) (→Comments) ← Previous diff		Current revision (05:24, 23 August 2013) (edit) Hommes (Talk | contribs) (→Comment-36)
Line 57:		Line 57:
	KH: The definition has be reformulated.		KH: The definition has be reformulated.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, the following action has been taken: RH: comment processed.</span>
	=== Comment-10 ===		=== Comment-10 ===
Line 88:		Line 90:
	=== Comment-15 ===		=== Comment-15 ===
-	TD: The Abbreviation "CWA" occurs here for the first time and has not been introduced. Maybe the whole chapter should start with a sentence like "The present CWA (Full Wording) specifies...."	+	TD: The Abbreviation "CWA" occurs here for the first time and has not been introduced. Maybe the whole chapter should start with a sentence like "The present CWA (Full Wording) on European Filing Rules specifies...."
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, CWA has been put in, in full: Included by RH</span>
		+
		+	=== Comment-16 ===
		+	TD: I think that examples should have a different layout. It might be useful to add after the definition a line stating: '''Example''': The xs:element ''xyz'' can be viewed as a ...". I would like to suggest this editorial strategy for all examples (it is used in ISO documents), but still have to check the layout format in CEN.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, the proposal is included, in full: Included by RH</span>
		+
		+	=== Comment-17 ===
		+	KH: Should there be a rule to prohibit XML fragments in scenario and segment?
		+
		+	=== Comment-18 ===
		+	TD: Maybe write "An XBRL taxonomy" instead of "A taxonomy". Just to stress again the link to XBRL, and having XBRL as the decision point.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, the proposed solutions has been adopted: Included by RH</span>
		+
		+	=== Comment-19 ===
		+	TD: Maybe write "the applicable taxonomy" instead of "the taxonomy". This refers then to the definition. Maybe mark the string in bold face to mark that it refers to a definition.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, the proposed solutions has been adopted: Included by RH</span>
		+
		+	=== Comment-20 ===
		+	TD: Second part of the definition is difficult to read!
		+
		+	1) I think it is not enough to write that an instance document is an XBRL file (so is the taxonomy also). I guess it would enough to add that an instance contains concrete values for the elements of the applicable XBRL taxonomy
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, the proposed solutions has been adopted: Included by RH</span>
		+
		+	2) In any case: the second part of the text is in my opinion rather a note, and not part of the definition. In ISO documents, one can add a NOTE to a definition (similar to the EXAMPLE case). If you agree I would go next very soon to the whole document and re-edit the definition, separating the NOTE parts from the definition part.
		+
		+	=== Comment-21 ===
		+	TD: Not sure about this comment now (since linkbase and formula should be known by the reader), but since the terms link base and formula are occuring quite often, mybe add a short definition for both terms.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, the proposed solutions has been adopted: Included by RH</span>
		+
		+	=== Comment-22 ===
		+	TD: "Data points" has not been introduced so far (it seems to me that this points to the Data Point Model, but maybe I am wrong here). Either leave the word "point" out, or add a definition about "data point".
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, the proposed solutions has been adopted: Included by RH</span>
		+
		+	=== Comment-23 ===
		+	TD: Maybe for all subsections here, add a short intro line, explaining what is the special case. What is a "context", a "footnote" etc. Or add "unit", "fact", "footnote" and "context" in the definitions.<br/>
		+	RH: These are XBRL syntax elements that contain aspects of the facts reported. The definition can be found in the XBRL 2.1 specification. I would be careful to copy all kinds of definitions from other specs.
		+
		+	=== Comment-24 ===
		+	CSSF/EB: We have had no need up to now for managing language versions of text contents in the past in spite of being a multi-language country; the content of the facts speaks for itself whatever language is used. If still you add such a facility, I hope for a clearer choice in the next version of the document because I do at present not know how to adapt our system to take this into account (I don't want to add several ways but only a single one to deal with languages of text fields).<br/>
		+
		+	RH: For human interpretation you are right that looking at the text you are able to tell what language it is (well, most times anyway). But computers are not that smart. So if you have a system that is presenting the instance in a template on the screen you may want to match the template language to the language retrieved from the instance.
		+	For your purpose I would guess that you would make a filing rule that states that only one language is allowed in an instance and that language can only be xx, yy, zz and is MUST be stated on the instance root element only. But we leave other regulators free in how they would like to deal with multi-language situations. Essentially the only rule is that ‘a’ language attribute must be in the instance if texts are in there.<br/>
		+
		+	CSSF/EB: Regarding 2.30, I am not too happy with the explanations because you there give no SHOULD or MUST rule that could be reinforced by an authority in case of need, but an alternative ("place a language attribute at one of several possible places, wherever the local authority of the local country feels like requiring it"). This creates again unnecessary incompatibilities which filing rules should try to eliminate among european instances. I remain of the opinion that if multi-language is felt to be a real european need in instances, then ONE mechanism with ONE way / place to put the attribute SHOULD be defined. <br/>
		+
		+	RH: In general there are two options in allowing multiple languages: <br/>
		+	# one language per instance (ergo: multiple instances, one per language, the Belgian way)
		+	# one instance with multiple languages (ergo: language per text based element, the Danish way)
		+
		+	Pro and cons <br/>
		+	Pro 1: Formula validation implicitFiltering works, processing of a complete instance, rendering based on language aspect
		+	Con 1: Each instance needs to carry all facts, also the dates and numerics. Extra validation is required to asses if all instances carry the same non string based values. Some validations may need to span all instances.
		+	Pro 2: All numerics and dates are communicated once, the texts have multiple languages in the same instance rendering based on XML file
		+	Con 2: Need to validate if all texts have all the used languages, formula don’t consider xml:lang as an predefined aspect so implicitFiltering mechanism may suffer (there is no designed filter, you would need a generalfilter or customattributefilter).<br/>
		+
		+	I would be hesitant to state one of these two mechanisms is the ‘better’ way. Maybe we can point to a ‘preferred’ way in Frankfurt.
		+
		+	CSSF/EB: as we are not strongly concerned (one language is enough, we'll probably impose the choice of any of the official languages in LU for use in all fields and instances of a report), we'll have a single instance per dataset resp. one (the same) language attribute for all text based fields. So we can use any of these 2 mechanisms without heavy changes to our system (We'll probably ignore the language feature anyway in internal procedures as we have neither means nor need to store that information, string contents being self-explaining to human readers). Let's hope Frankfurt gives the necessary input to choose a light solution in the spirit of the KISS principle without creating too many collateral disadvantages. I also hope to have in the end clear indications on how regulators that allow NO multiple languages should work to stay compatible with their multi-language colleagues.
		+
		+	May be we should add over here to our traditional:<br/>
		+	# single entity per instance
		+	# single reporting period per instance
		+	# single currency per instance
		+	# single consolidation status per instance (consolidated, sub-consolidated, solo)
		+	# single audit status per instance (audited, not audited figures)
		+
		+	a 6th one <br/>
		+	# single language for text fields per instance
		+
		+	=== Comment-25 ===
		+	''IB: rule 2.23 is''
		+
		+	<span style="color:blue; font-weight:bold">2.23&nbsp;&nbsp;</span> '''xbrli:segment MUST NOT be used.'''
		+	<br/>
		+	As xbrli:scenario and xbrli:segment elements are treated as mutually exclusive, using both of them is prohibited.
		+	<br>
		+
		+	''It is suggested explaining the practical reasons and rephrase as RECOMMENDATION. Some Supervisors seems to use xbrli:segment when defining additional dimensions to the primary taxonomy, as fast solution instead extending dimensions.''
		+	<br>
		+
		+	<span style="color:blue; font-weight:bold">2.23&nbsp;&nbsp;</span> '''xbrli:scenario is REQUIRED.'''
		+	<br/>
		+	xbrli:scenario and xbrli:segment elements are both equivalent containers (especially for dimensional information in the instance document). The European best practice is using only xbrli:scenario, hence simplifying the creation and consumption of instances by not using xbrli:segment. Using simultaneously xbrli:scenario and xbrli:segment is unnecessarily more complex.
		+
		+	=== Comment-26 ===
		+	RH: The argument for removal of the @xml:base as a recommendation (because the software is more mature now) seems odd. It's not only about rendering and validation software that may be more mature nowadays, but is also about mapping software which many reporters and receivers are creating for themselves which is not mature at all. Since the original argument (no semantic reason for the attribute) is still valid I see no reason to drop the rule (as a recommendation).
		+	KH: Agreement: Recommendation is useful to be added especially for software that is more oriented to XML than XBRL.
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule will be added back into the list : Included by KH</span>
		+
		+	=== Comment-27 ===
		+	RH: The argument NOT declaring unused namespaces (because they clutter the instance and are not needed) still stands as a recommendation. If no rule exists it is not even a recommendation, it states: go right ahead. Just because it's XML valid to do so, doesn't make it a best practice.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule is not needed : Included by KH</span>
		+
		+	=== Comment-28 ===
		+	PdW: I think we probably need a separate rule requiring taxonomy publishers to structure their taxonomies in such a way that users need only reference a single entrypoint.<br/>
		+	RH: If such a rule would be enforced, it would go into the taxonomy architecture document, not in the filing rules.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, text has been changed : Included by KH</span>
		+
		+	=== Comment-29 ===
		+	PdW: I still have reservations of this rule. A requirement to remove comments may create an unnecessary burden on <br/>
		+	RH: I point to the final words in comment-27
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule is not needed : Included by KH</span>
		+
		+	=== Comment-30 ===
		+	KS: Unused contexts should not prevent a processing.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule is not needed : Included by KH</span>
		+
		+	=== Comment-31 ===
		+	KS: Could be possible in the future to have more identifiers. Rule should be stable.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, text has been added that the DTS author determines the number of reporters in an instance : Included by KH</span>
		+
		+	=== Comment-32 ===
		+	RH: Reporting facts from historic periods within a current report stating in its context that they are from the current period, is asking for trouble. It requires that the historic fact gets a time dimension stating its correct period or its primary stating the original period. If words like 'previous period' etc. are not sufficient, the time dimension will get members expressing exact periods of time making it necessary to fall back to a typed dimension because not every reporter has the same 1-1 till 31-12 financial periods.
		+	KH: Roland is going to send an email to Owen and Victor to raise his concerns.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, text of the rule has been amended: Included by KH</span>
		+
		+	=== Comment-33 ===
		+	PdW: I suspect that it’s too late to change this, but most other taxonomies in widespread use segment (US-GAAP, UK-GAAP). I believe that IFRS uses scenario, but real world adoption of that taxonomy is very limited.<br/>
		+	RH: It depends on what 'most other taxonomies' is regarded. If there are only two taxonomies using xbrli:segment, but they represent the majority of filings, would that qualify as 'most'? IFRS, GRI, old style FinRep and CoRep (and its sisters like LE, BSIMIR etc) and all SBR projects are using scenario. More taxonomies, less filings.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule is not needed : Included by KH</span>
		+
		+	=== Comment-34 ===
		+	KS: Text needs to be rephrased by Herm.
		+
		+	=== Comment-35 ===
		+	PdW: This section appears to directly contradict section 4.6.5 of XBRL 2.1. We should not be repeating the content of other specifications here, and should certainly not be attempting to redefine them.<br/>
		+	IB: The goal of the point "2.27 @decimals" is for avoid rounding or truncation in the preparer, that reduces the unnecessarily the precision of the facts.
		+
		+	Rounding or truncation is a classical bad practice in reporting entities by forcing leading zeroes after the accurate @decimals. The 2.27 goal is simply to require to reporting entities a full respect to all the original digits in the decimal figures, with no modification at all. Is a responsibility of the regulators defining Formulae validations with the applicable thresholds.
		+
		+	The description of interval arithmetic is explanatory, and is based in the use of consistency assertions for Formulae. http://www.xbrl.org/Specification/consistencyAssertions/REC-2009-06-22/consistencyAssertions-REC-2009-06-22.html
		+
		+	According to Victor Morilla, the XBRL 2.1 has a room for interpretation at http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html#_4.6.5
		+
		+	"The @decimals attribute MUST be an integer or the value "INF" that specifies the number of decimal places to which the value of the fact represented may be considered accurate."
		+
		+	However, it is not formally defined what to do with the "inaccurate" decimal places.
		+
		+	In the 5th example, the situation is evident:
		+	@decimals=2, reported fact=10.009, Read as 10.00 (after omitting or zeroing any spurious digits) Known to be GE 9.995 Known to be LT 10.005
		+
		+	A fact with a value 10.009 is "Known to be LT 10.005" ? More precisely: considering 10.009 LT 10.005 creates problems. Such contradictions using calculation linkbase are to be avoided using Formulae
		+
		+	Therefore, to avoid this inconsistency, the recommended agreement for Formula "acceptance radius of a consistency assertion" in Europe would be as following:
		+	@decimals=2, reported fact=10.009, Acceptance radius= +- 0.5*10^(-2)= +- 0.005 Known to be GE 10.004 Known to be LT 10.014
		+
		+	All is now consistent, as now 10.004 < 10.009 < 10.014
		+
		+	It is no problem in rephrasing the current explanation:
		+	"If the @decimals attribute of a numeric fact is not equal to "INF", then the numeric fact is interpreted as interval arithmetic of the numeric fact ± 0.5(10 ^ - @decimals ).
		+	This rule is valuable when XBRL Formulas are used to validate the numeric facts."
		+
		+	In something more precise (at your best criteria) as:
		+	"If the @decimals attribute of a numeric fact is not equal to "INF", then the numeric fact is interpreted as having an acceptance radius of ± 0.5(10 ^ - @decimals ) for XBRL Formulae consistency assertions.
		+	This rule is valuable when XBRL Formulas are used to validate the numeric facts using interval arithmetic."
		+	KS: An email will be sent to Paul, Owen and Ignacio to ask for possible changes on the text of the rule.
		+
		+	=== Comment-36 ===
		+	PdW: For numeric facts, “empty” is not an option: the third option is “not reported”. In my opinion, allowing xsl:nil generally causes my problems than it solves. I would suggest that the CWA advice should be that facts should not be reported using nil=”true” unless the receiving regulator has explicitly permitted it, and ascribed a specific meaning to its use. <br/>
		+	RH: I agree with Paul that it should be preferred to leave xsi:nil out unless specific use has been addressed. It's a contest of who has the latest say in a fact. The regulator says its required (by xml schema minOccurs, or Formula) and the reporter states, I don't have it.
		+	KH: Text will be amended by Roland to express that nil should be defined by the regulator that enforces its usage. Unless only zero or meaningful valus should be reported.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule is modified according to above : Included by RH</span>
		+
		+	=== Comment-37 ===
		+	PdW: We should delete this rule, as it’s not adding anything that isn’t already covered by the XML and XBRL specifications. In particular, we should not be redefining the lexical representation of xsd:decimals: the XML data types spec is the canonical source for that. I have no idea if the EBNF presented here is equivalent to the canonical definition, but there is no benefit in including it here.<br/>
		+	IB: In the point 2.30 decimal representation, I agree in your advice, by substituting the current phrase:
		+
		+	"The legal decimal representation on Extended Backus-Naur Form is:
		+	<digit> = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;
		+	<number> = [ "+" | "-" ] { <digit> } <digit> [ "." { <digit> } ] ;
		+	The legal decimal representation is therefore defined as an optional sign "+" or "-", followed by one or more decimal digits ("0" to "9") and, optionally, a decimal point "." followed by zero or more decimal digits.
		+
		+	EXAMPLE 0 +0. 1234 -1234 1234.56 +123456.7890123456"
		+
		+	By the more clear current description in the XML specification, as:
		+
		+	"See the formal XML decimal lexical representation at http://www.w3.org/TR/xmlschema-2/#decimal-lexical-representation
		+
		+	decimal has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39) separated by a period as a decimal indicator. An optional leading sign is allowed. If the sign is omitted, "+" is assumed.
		+	Leading and trailing zeroes are optional. If the fractional part is zero, the period and following zero(es) can be omitted. For example: -1.23, 12678967.543233, +100000.00, 210"
		+
		+	Both are equivalent, but, as you say, why to redefine the XML specification?
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule is not needed : Included by KH</span>
		+
		+	=== Comment-38 ===
		+	PdW: I don’t think this rule is necessary. It may be useful for preparers to include ids. There may be developments in the future for which IDs are useful. Including unused ids is harmless. I’d be in favour of removing this rule. <br/>
		+	RH: It's harmless all right, but if it's in it should be explained by the one who put it there to prevent other users directing some kind of unintended meaning or worse derive some software function from them.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule is not needed : Included by KH</span>
		+
		+	=== Comment-39 ===
		+	PdW: I’d be in favour of deleting this rule. Duplicate units make absolutely no difference to compliant software, and may actually be useful for streaming. All this rule does is place an unnecessary syntactic constraint on creation software.<br/>
		+	PdW: Duplicated units will not disturb the comparison of facts in any XBRL compliant software. We should not tolerate non-compliant software.<br/>
		+	KS: Processing should not be prevented. Just a warning.<br/>
		+	RH: There is no semantic reason for duplicates so don't sent them. Clear the mess on the sender side, not the receiver side.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule is not needed. Equivalent to rule concering duplicate contexts : Included by KH</span>
		+
		+	=== Comment-40 ===
		+	PdW: I think that there is a more important issue here, which is whether regulators should impose UTR validation on documents received.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, a rule can only be imposed by a regulator but not by CEN: Included by KH</span>
		+
		+	=== Comment-41 ===
		+	KS: Text needs to be rephrased by Herm. Sense: not to use currency for precision
		+
		+	=== Comment-42 ===
		+	PdW: I don’t understand how this rule relates to the previous one.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed, rule is not needed : Included by KH</span>
	=== Suggestions ===		=== Suggestions ===
Line 99:		Line 327:
	Suggestion:<br/>		Suggestion:<br/>
	A single entrypoint using link:schemaRef addressing the official applicable taxonomy through an URL MUST be used.		A single entrypoint using link:schemaRef addressing the official applicable taxonomy through an URL MUST be used.
		+
		+	<span style="background-color:#BCF5A9">The discussion is closed: Included by KH</span>

---

Current revision

Contents 1 Comments 1.1 Comment-01 1.2 Comment-02 1.3 Comment-03 1.4 Comment-04 1.5 Comment-05 1.6 Comment-06 1.7 Comment-07 1.8 Comment-08 1.9 Comment-09 1.10 Comment-10 1.11 Comment-11 1.12 Comment-12 1.13 Comment-13 1.14 Comment-14 1.15 Comment-15 1.16 Comment-16 1.17 Comment-17 1.18 Comment-18 1.19 Comment-19 1.20 Comment-20 1.21 Comment-21 1.22 Comment-22 1.23 Comment-23 1.24 Comment-24 1.25 Comment-25 1.26 Comment-26 1.27 Comment-27 1.28 Comment-28 1.29 Comment-29 1.30 Comment-30 1.31 Comment-31 1.32 Comment-32 1.33 Comment-33 1.34 Comment-34 1.35 Comment-35 1.36 Comment-36 1.37 Comment-37 1.38 Comment-38 1.39 Comment-39 1.40 Comment-40 1.41 Comment-41 1.42 Comment-42 1.43 Suggestions

Comments

Comment-01

RH: Can we use only 'instance' as the term for a report, XBRL document, filing document etc.?
KH: I agree. I'm going to change it to instance document.
The discussion is closed, the following action has been taken: Changed by KH

Comment-02

RH: This 'rule' states that there is no rule for instance naming. I suggest to alter the rule to: Any taxonomy author MUST prescribe instance file naming conventions. We can make a couple of suggestions on how other projects have created such rules.
KH: There need not be any file name conventions. So I would suggest to use CAN instead of MUST.
RH: This touches on a more basic point; if we do not set rules on anything, should we mention it at all? Are examples than still appropriate? IMO it is required to have it explicit (I always favor explicit to implicit). For rules MUST and MAY are the most appropriate terms. So this one should revert to a MAY rule. TD: Is this aspect of file naming not something that should be in the Architecture Document (Roland saying that the author of a taxonomy must provide for a file naming convention. So that instance documents generated on the basis of such a schema will have per definition a file name)
RH: CEN meeting 2012-10-29: Rules should be made explicit, also when the rule is 'to have no rule'.
The discussion is closed, the following action has been taken: Rules have been explicit by RH

Comment-03

Rule: 2.22 xbrli:xbrl/xbrli:unit declarations SHOULD adhere to XBRL international unit registry content
KH: Rule should be reformulated.
RH: Suggestion has been made, SHOULD NOT rule on creating units that are in utr.

Comment-04

KH: Should it be allowed ot define units?
RH: CEN meeting 2012-10-29: No scale on numerics is allowed. Rather: NSA's should conform to the utr of XII and put any new units in there.
The discussion is closed, the following action has been taken: RH: rule is no scale allowed.

Comment-05

KH: Rule to be added that no extension of reporting entities on European taxonomies are allowed.
RH: CEN meeting 2012-10-29, not extensions by reporters allowed
The discussion is closed, the following action has been taken: Rule 1.8 no extensions allowed created.

Comment-06

KH: The schemaRef should contain the full schemalocation because the version is not contained in the namespace.
The discussion is closed, the following action has been taken: RH: comment processed in rule.

Comment-07

TD: In general: the word to be defined should not appear in the definition
The discussion is closed, the following action has been taken: RH: comment processed in rule.

Comment-08

TD: I would add a definition for the "filer" and include there the fact that the filer should own the name of the authority. I would also add a defintion for "to file", in case this is a technical term here.
The discussion is closed, the following action has been taken: RH: comment processed in entry, to file is the general process of filing anything with an authority.

Comment-09

TD: For "entity" I found this deinfition (http://www.aasb.gov.au/admin/file/content102/c3/SAC1_8-90_2001V.pdf)

"entity" means any legal, administrative, or fiduciary arrangement, organisational structure or other party (including a person) having the capacity to deploy scarce resources in order to achieve objectives; and

again, we should avoid to have the (parts of) term we define, inside the definition.

KH: The definition has be reformulated.

The discussion is closed, the following action has been taken: RH: comment processed.

Comment-10

TD: The additional sentence "A listing of all taxonomy files respective modules recognised in the filing system should be provided on a web location. " is not necessary
RH: What this text is showing is that DTS authors MUST provide a list of URL's to entrypoints on the internet. Maybe the rule is self explaining?

Comment-11

TD: I think that the concept "Entry Point" should be defined before
The discussion is closed, the following action has been taken: Included by RH

Comment-12

KH: A rule should be added that always the complete package (file) should be sent, not only an update.
DDB: I think this makes it less flexible, partial submission can be very efficient.
RH: CEN meeting 2012-10-29: Allowing partial data brings a lot of technical complexity because validation and presentation of the instance is no longer possible. OTOH the internal processes at reporters may be designed to create only parts of certain reports. Forcing only complete submissions would force internal restructuring with these reporters. Golden rule is that every XBRL instance is XBRL standards valid.
Interesting case: if, because of size restrictions, the instance is being split across multiple instances, a 'total' assertion may not be functioning correctly. In this case the 'golden rule' is being broken because of technical reasons. The DTS owner allowing partial submissions need to guarantee ex-post that all original rules of the DTS are processable.
Sending partial submissions by reporters becomes a choice of the NSA. The header of the message will cater for an element that states if the instance is a 'full' replacement or a 'incremental' submission.
All risks involved with partial submissions are upon the NSA allowing it. The recommendation will be to sent complete packages. (the term Package is not defined!)

Comment-13

RH: Where is the 'default' language declared? Better not have any implicit meaning since every country will allow it's own 'default' which would result in a mess at central European regulators.
Propose to change the rule into: Non numeric facts MUST be clarified to what language is being used.
The purpose of the xml:lang is to enable the receiver to match presentation templates with the facts in the same language as the (non-numeric) facts have been put. ENABLE, not FORCES.

The discussion is closed, the proposed solutions has been adopted: Included by KH

Comment-14

RH/KH: Because of size restrictions, the instance could be split across multiple instances, a 'total' assertion based on XBRL Formula may not be functioning correctly. In this case the instance document wouldn't be valid. The receiver of the data allowing the splitting of submissions need to guarantee ex-post that all original rules of the DTS including Formulas are processable.

Comment-15

TD: The Abbreviation "CWA" occurs here for the first time and has not been introduced. Maybe the whole chapter should start with a sentence like "The present CWA (Full Wording) on European Filing Rules specifies...."

The discussion is closed, CWA has been put in, in full: Included by RH

Comment-16

TD: I think that examples should have a different layout. It might be useful to add after the definition a line stating: Example: The xs:element xyz can be viewed as a ...". I would like to suggest this editorial strategy for all examples (it is used in ISO documents), but still have to check the layout format in CEN.

The discussion is closed, the proposal is included, in full: Included by RH

Comment-17

KH: Should there be a rule to prohibit XML fragments in scenario and segment?

Comment-18

TD: Maybe write "An XBRL taxonomy" instead of "A taxonomy". Just to stress again the link to XBRL, and having XBRL as the decision point.

The discussion is closed, the proposed solutions has been adopted: Included by RH

Comment-19

TD: Maybe write "the applicable taxonomy" instead of "the taxonomy". This refers then to the definition. Maybe mark the string in bold face to mark that it refers to a definition.

The discussion is closed, the proposed solutions has been adopted: Included by RH

Comment-20

TD: Second part of the definition is difficult to read!

1) I think it is not enough to write that an instance document is an XBRL file (so is the taxonomy also). I guess it would enough to add that an instance contains concrete values for the elements of the applicable XBRL taxonomy

The discussion is closed, the proposed solutions has been adopted: Included by RH

2) In any case: the second part of the text is in my opinion rather a note, and not part of the definition. In ISO documents, one can add a NOTE to a definition (similar to the EXAMPLE case). If you agree I would go next very soon to the whole document and re-edit the definition, separating the NOTE parts from the definition part.

Comment-21

TD: Not sure about this comment now (since linkbase and formula should be known by the reader), but since the terms link base and formula are occuring quite often, mybe add a short definition for both terms.

The discussion is closed, the proposed solutions has been adopted: Included by RH

Comment-22

TD: "Data points" has not been introduced so far (it seems to me that this points to the Data Point Model, but maybe I am wrong here). Either leave the word "point" out, or add a definition about "data point".

The discussion is closed, the proposed solutions has been adopted: Included by RH

Comment-23

TD: Maybe for all subsections here, add a short intro line, explaining what is the special case. What is a "context", a "footnote" etc. Or add "unit", "fact", "footnote" and "context" in the definitions.
RH: These are XBRL syntax elements that contain aspects of the facts reported. The definition can be found in the XBRL 2.1 specification. I would be careful to copy all kinds of definitions from other specs.

Comment-24

CSSF/EB: We have had no need up to now for managing language versions of text contents in the past in spite of being a multi-language country; the content of the facts speaks for itself whatever language is used. If still you add such a facility, I hope for a clearer choice in the next version of the document because I do at present not know how to adapt our system to take this into account (I don't want to add several ways but only a single one to deal with languages of text fields).

RH: For human interpretation you are right that looking at the text you are able to tell what language it is (well, most times anyway). But computers are not that smart. So if you have a system that is presenting the instance in a template on the screen you may want to match the template language to the language retrieved from the instance. For your purpose I would guess that you would make a filing rule that states that only one language is allowed in an instance and that language can only be xx, yy, zz and is MUST be stated on the instance root element only. But we leave other regulators free in how they would like to deal with multi-language situations. Essentially the only rule is that ‘a’ language attribute must be in the instance if texts are in there.

CSSF/EB: Regarding 2.30, I am not too happy with the explanations because you there give no SHOULD or MUST rule that could be reinforced by an authority in case of need, but an alternative ("place a language attribute at one of several possible places, wherever the local authority of the local country feels like requiring it"). This creates again unnecessary incompatibilities which filing rules should try to eliminate among european instances. I remain of the opinion that if multi-language is felt to be a real european need in instances, then ONE mechanism with ONE way / place to put the attribute SHOULD be defined.

RH: In general there are two options in allowing multiple languages:

1. one language per instance (ergo: multiple instances, one per language, the Belgian way)
2. one instance with multiple languages (ergo: language per text based element, the Danish way)

Pro and cons
Pro 1: Formula validation implicitFiltering works, processing of a complete instance, rendering based on language aspect Con 1: Each instance needs to carry all facts, also the dates and numerics. Extra validation is required to asses if all instances carry the same non string based values. Some validations may need to span all instances. Pro 2: All numerics and dates are communicated once, the texts have multiple languages in the same instance rendering based on XML file Con 2: Need to validate if all texts have all the used languages, formula don’t consider xml:lang as an predefined aspect so implicitFiltering mechanism may suffer (there is no designed filter, you would need a generalfilter or customattributefilter).

I would be hesitant to state one of these two mechanisms is the ‘better’ way. Maybe we can point to a ‘preferred’ way in Frankfurt.

CSSF/EB: as we are not strongly concerned (one language is enough, we'll probably impose the choice of any of the official languages in LU for use in all fields and instances of a report), we'll have a single instance per dataset resp. one (the same) language attribute for all text based fields. So we can use any of these 2 mechanisms without heavy changes to our system (We'll probably ignore the language feature anyway in internal procedures as we have neither means nor need to store that information, string contents being self-explaining to human readers). Let's hope Frankfurt gives the necessary input to choose a light solution in the spirit of the KISS principle without creating too many collateral disadvantages. I also hope to have in the end clear indications on how regulators that allow NO multiple languages should work to stay compatible with their multi-language colleagues.

May be we should add over here to our traditional:

1. single entity per instance
2. single reporting period per instance
3. single currency per instance
4. single consolidation status per instance (consolidated, sub-consolidated, solo)
5. single audit status per instance (audited, not audited figures)

a 6th one

1. single language for text fields per instance

Comment-25

IB: rule 2.23 is

2.23   xbrli:segment MUST NOT be used.
As xbrli:scenario and xbrli:segment elements are treated as mutually exclusive, using both of them is prohibited.

It is suggested explaining the practical reasons and rephrase as RECOMMENDATION. Some Supervisors seems to use xbrli:segment when defining additional dimensions to the primary taxonomy, as fast solution instead extending dimensions.

2.23   xbrli:scenario is REQUIRED.
xbrli:scenario and xbrli:segment elements are both equivalent containers (especially for dimensional information in the instance document). The European best practice is using only xbrli:scenario, hence simplifying the creation and consumption of instances by not using xbrli:segment. Using simultaneously xbrli:scenario and xbrli:segment is unnecessarily more complex.

Comment-26

RH: The argument for removal of the @xml:base as a recommendation (because the software is more mature now) seems odd. It's not only about rendering and validation software that may be more mature nowadays, but is also about mapping software which many reporters and receivers are creating for themselves which is not mature at all. Since the original argument (no semantic reason for the attribute) is still valid I see no reason to drop the rule (as a recommendation). KH: Agreement: Recommendation is useful to be added especially for software that is more oriented to XML than XBRL. The discussion is closed, rule will be added back into the list : Included by KH

Comment-27

RH: The argument NOT declaring unused namespaces (because they clutter the instance and are not needed) still stands as a recommendation. If no rule exists it is not even a recommendation, it states: go right ahead. Just because it's XML valid to do so, doesn't make it a best practice.

The discussion is closed, rule is not needed : Included by KH

Comment-28

PdW: I think we probably need a separate rule requiring taxonomy publishers to structure their taxonomies in such a way that users need only reference a single entrypoint.
RH: If such a rule would be enforced, it would go into the taxonomy architecture document, not in the filing rules.

The discussion is closed, text has been changed : Included by KH

Comment-29

PdW: I still have reservations of this rule. A requirement to remove comments may create an unnecessary burden on
RH: I point to the final words in comment-27

The discussion is closed, rule is not needed : Included by KH

Comment-30

KS: Unused contexts should not prevent a processing.

The discussion is closed, rule is not needed : Included by KH

Comment-31

KS: Could be possible in the future to have more identifiers. Rule should be stable.

The discussion is closed, text has been added that the DTS author determines the number of reporters in an instance : Included by KH

Comment-32

RH: Reporting facts from historic periods within a current report stating in its context that they are from the current period, is asking for trouble. It requires that the historic fact gets a time dimension stating its correct period or its primary stating the original period. If words like 'previous period' etc. are not sufficient, the time dimension will get members expressing exact periods of time making it necessary to fall back to a typed dimension because not every reporter has the same 1-1 till 31-12 financial periods. KH: Roland is going to send an email to Owen and Victor to raise his concerns.

The discussion is closed, text of the rule has been amended: Included by KH

Comment-33

PdW: I suspect that it’s too late to change this, but most other taxonomies in widespread use segment (US-GAAP, UK-GAAP). I believe that IFRS uses scenario, but real world adoption of that taxonomy is very limited.
RH: It depends on what 'most other taxonomies' is regarded. If there are only two taxonomies using xbrli:segment, but they represent the majority of filings, would that qualify as 'most'? IFRS, GRI, old style FinRep and CoRep (and its sisters like LE, BSIMIR etc) and all SBR projects are using scenario. More taxonomies, less filings.

The discussion is closed, rule is not needed : Included by KH

Comment-34

KS: Text needs to be rephrased by Herm.

Comment-35

PdW: This section appears to directly contradict section 4.6.5 of XBRL 2.1. We should not be repeating the content of other specifications here, and should certainly not be attempting to redefine them.
IB: The goal of the point "2.27 @decimals" is for avoid rounding or truncation in the preparer, that reduces the unnecessarily the precision of the facts.

Rounding or truncation is a classical bad practice in reporting entities by forcing leading zeroes after the accurate @decimals. The 2.27 goal is simply to require to reporting entities a full respect to all the original digits in the decimal figures, with no modification at all. Is a responsibility of the regulators defining Formulae validations with the applicable thresholds.

The description of interval arithmetic is explanatory, and is based in the use of consistency assertions for Formulae. http://www.xbrl.org/Specification/consistencyAssertions/REC-2009-06-22/consistencyAssertions-REC-2009-06-22.html

According to Victor Morilla, the XBRL 2.1 has a room for interpretation at http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html#_4.6.5

"The @decimals attribute MUST be an integer or the value "INF" that specifies the number of decimal places to which the value of the fact represented may be considered accurate."

However, it is not formally defined what to do with the "inaccurate" decimal places.

In the 5th example, the situation is evident: @decimals=2, reported fact=10.009, Read as 10.00 (after omitting or zeroing any spurious digits) Known to be GE 9.995 Known to be LT 10.005

A fact with a value 10.009 is "Known to be LT 10.005" ? More precisely: considering 10.009 LT 10.005 creates problems. Such contradictions using calculation linkbase are to be avoided using Formulae

Therefore, to avoid this inconsistency, the recommended agreement for Formula "acceptance radius of a consistency assertion" in Europe would be as following: @decimals=2, reported fact=10.009, Acceptance radius= +- 0.5*10^(-2)= +- 0.005 Known to be GE 10.004 Known to be LT 10.014

All is now consistent, as now 10.004 < 10.009 < 10.014

It is no problem in rephrasing the current explanation: "If the @decimals attribute of a numeric fact is not equal to "INF", then the numeric fact is interpreted as interval arithmetic of the numeric fact ± 0.5(10 ^ - @decimals ). This rule is valuable when XBRL Formulas are used to validate the numeric facts."

In something more precise (at your best criteria) as: "If the @decimals attribute of a numeric fact is not equal to "INF", then the numeric fact is interpreted as having an acceptance radius of ± 0.5(10 ^ - @decimals ) for XBRL Formulae consistency assertions. This rule is valuable when XBRL Formulas are used to validate the numeric facts using interval arithmetic." KS: An email will be sent to Paul, Owen and Ignacio to ask for possible changes on the text of the rule.

Comment-36

PdW: For numeric facts, “empty” is not an option: the third option is “not reported”. In my opinion, allowing xsl:nil generally causes my problems than it solves. I would suggest that the CWA advice should be that facts should not be reported using nil=”true” unless the receiving regulator has explicitly permitted it, and ascribed a specific meaning to its use.
RH: I agree with Paul that it should be preferred to leave xsi:nil out unless specific use has been addressed. It's a contest of who has the latest say in a fact. The regulator says its required (by xml schema minOccurs, or Formula) and the reporter states, I don't have it. KH: Text will be amended by Roland to express that nil should be defined by the regulator that enforces its usage. Unless only zero or meaningful valus should be reported.

The discussion is closed, rule is modified according to above : Included by RH

Comment-37

PdW: We should delete this rule, as it’s not adding anything that isn’t already covered by the XML and XBRL specifications. In particular, we should not be redefining the lexical representation of xsd:decimals: the XML data types spec is the canonical source for that. I have no idea if the EBNF presented here is equivalent to the canonical definition, but there is no benefit in including it here.
IB: In the point 2.30 decimal representation, I agree in your advice, by substituting the current phrase:

  "The legal decimal representation on Extended Backus-Naur Form is: 
  <digit> = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;
  <number>  = [ "+" | "-" ] { <digit> } <digit> [ "." { <digit> } ] ;
  The legal decimal representation is therefore defined as an optional sign "+" or "-", followed by one or more decimal digits ("0" to "9") and, optionally, a decimal point "." followed by zero or more decimal digits.

  EXAMPLE	 0 +0.   1234 -1234   1234.56  +123456.7890123456"

By the more clear current description in the XML specification, as:

  "See the formal XML decimal lexical representation at http://www.w3.org/TR/xmlschema-2/#decimal-lexical-representation 

  decimal has a lexical representation consisting of a finite-length sequence of decimal digits (#x30-#x39) separated by a period as a decimal indicator. An optional leading sign is allowed. If the sign is omitted, "+" is assumed.
  Leading and trailing zeroes are optional. If the fractional part is zero, the period and following zero(es) can be omitted. For example: -1.23, 12678967.543233, +100000.00, 210"

Both are equivalent, but, as you say, why to redefine the XML specification?

The discussion is closed, rule is not needed : Included by KH

Comment-38

PdW: I don’t think this rule is necessary. It may be useful for preparers to include ids. There may be developments in the future for which IDs are useful. Including unused ids is harmless. I’d be in favour of removing this rule.
RH: It's harmless all right, but if it's in it should be explained by the one who put it there to prevent other users directing some kind of unintended meaning or worse derive some software function from them.

The discussion is closed, rule is not needed : Included by KH

Comment-39

PdW: I’d be in favour of deleting this rule. Duplicate units make absolutely no difference to compliant software, and may actually be useful for streaming. All this rule does is place an unnecessary syntactic constraint on creation software.
PdW: Duplicated units will not disturb the comparison of facts in any XBRL compliant software. We should not tolerate non-compliant software.
KS: Processing should not be prevented. Just a warning.
RH: There is no semantic reason for duplicates so don't sent them. Clear the mess on the sender side, not the receiver side.

The discussion is closed, rule is not needed. Equivalent to rule concering duplicate contexts : Included by KH

Comment-40

PdW: I think that there is a more important issue here, which is whether regulators should impose UTR validation on documents received.

The discussion is closed, a rule can only be imposed by a regulator but not by CEN: Included by KH

Comment-41

KS: Text needs to be rephrased by Herm. Sense: not to use currency for precision

Comment-42

PdW: I don’t understand how this rule relates to the previous one.

The discussion is closed, rule is not needed : Included by KH

Suggestions

RH: As per telecall 20121108 a couple of rules MAY be merged. These are:
There MUST NOT be more than one link:schemaRef in an instance
Reporting entities SHOULD use only one of entrypoint schemas as specified in the applicable taxonomy.
link:schemaRef MUST contain the full URL as published on the internet
Reporting entities SHOULD use one of the taxonomies as specified in the filing system as the applicable taxonomy.

Suggestion:
A single entrypoint using link:schemaRef addressing the official applicable taxonomy through an URL MUST be used.

The discussion is closed: Included by KH