Relationships
– Generic rules
Public Working Draft October, 2009
Status
Circulation of this Public Working
Draft is unrestricted. Other documents may supersede this document. Recipients
are invited to submit comments to tapwg@xbrl.org,
and to submit notification of any relevant patent rights of which they are
aware and provide supporting documentation.
This document describes updates on
the rules that were published in “FRTA Recommendation 2005-04-25 with errata
from 2006-03-20.doc”. It highlights possible best practices in particular
circumstances. It seeks public comment on these issues as part of the process
of establishing best practices for XBRL projects. This RFC assumes a basic familiarity with the
use and principles of XBRL
Editor:
Roland
Hommes, roland@rhocon.nl
Contributors:
CH:
Charlie Hoffman
EC:
Eric Cohen
YN:
Yossi Newman
PR: Pascal Rodriquez
MP:
Maciej Piechocki
GLG:
Gianluca Garbelotto
MK:
Makoto Koizumi
PC:
Peter Calvert
MS:
Mark Schnitzer
VM:
Victor Morilla
Table of Contents
Appendix C – Intellectual property
status
Because of the volume of rules stated in the FRTA document, a division has been made to guarantee workable RFC documents. This RFC is about rules that have generic appliance and are dealing with relationships. Most of these rules were captured in chapter 3 of the FRTA document. Each of the existing rules will be listed here as a paragraph of chapter two and suitable comments will be inserted. Each comment section will conclude with a recommendation for adjustment or removal of the existing text if appropriate.
The reader is requested to evaluate the comments and put
more comments forward if they are deemed necessary to make an appropriate
evaluation of the necessary changes to the current text of the FRTA rule. The final
texts of the rules will be published as a minor release of the FRTA document
which will also be available for the public for comments.
|
A
linkbase must not include any link elements (simple,
resource, extended, or arc) not in an XBRL module or in the XBRL 2.1
Specification. Although XBRL allows linkbases to be extended with
additional XLink constructs, the set of schemas and linkbases comprising a
FRTA compliant DTS is limited to those defined in the current XBRL Specification
or Module Recommendations. |
RH: stands
EC: Generic Link; is that compromising this rule? (RH: No, generic Link is an XBRL Module)
CH: XDT roles were new roles that did not make it to the LRR. Maybe it needs rewording? There are other projects that have created roles that are still not in the LRR because of the process. Goto-san and Walter may have opinions about how roles are being entered in the LRR. (RH: This rule is about elements, not roleTypes)
|
An
arc must have only its standard or LRR approved arc
role. A FRTA-compliant DTS must not use
any arc roles except those documented in the XBRL Specification or approved
in the LRR. This does not prevent the
publication of an additional set of schemas, role definitions and linkbases
that constitute a non-FRTA compliant superset of a FRTA-compliant DTS. |
RH: stands
YN: LRR requests could work with a status indicator on each line. Otherwise large projects create their own sets which suppliers cannot check and that would create interoperability problems. (RH: LRR specification has the ‘<lrr:status> element that indicates PWD, CR, REC etc.)
CH: This is the same problem with custom attributes like the ‘deprecated’ status on concepts, there is no mechanism that states how XSD extensions with EXTERNAL functionality should be implemented.
|
The
label and reference elements must have only their
standard or LRR approved resource roles. The set of label and reference roles defined in Sections
5.2.2.2 (Table 8) and 5.2.3.2.1 (Table 9) of the XBRL 2.1 Specification, and
any label and reference roles defined in the LRR, are all that are allowed in
labelLink
and referenceLink elements. |
RH: stands
CH: There is a difference between standard and XII recognized roles. The relationship roles text needs to prohibit the error messages that were generated when XDT came up first.
|
An extended-type link role must have no processing semantics other than specified by
XBRL. The only processing semantics that XBRL gives the xlink:role
attribute on extended‑type links is that the values partition the sets
of arcs in a DTS into distinct sets called link base sets. This is the only semantics allowed
for the xlink:role. |
RH: stands
|
A
schema must not define a role type that duplicates a
definition in the DTS whose starting point is the schema defining that role
type. An equivalent formulation of this rule is that a
schema-rooted DTS must not contain s‑equal
role types. Although a FRTA compliant
taxonomy is constrained to use roles as shown in Table 5,
the definitions of those roles may occur in various
locations; this rule ensures that only one definition is used within a given
DTS, because a taxonomy author can control this but not control the DTS of
any instances. This rule also implies
that the authoritative location of the role definition should
be used. |
RH: stands
|
Roles
and arc roles from XBRL, XBRL modules, and the LRR should
be used in preference to defining new roles. This is a logical consequence of the fact that each of
these sources has the status of an XBRL International recommendation. |
RH: stands
|
All arcs
within an extended-type link must have the same arc
role. The
XML Linking Language [XLINK] forbids duplicate arcs
within a given extended-type link, even when the arcs in question have
different arc roles. Conforming XBRL
processors detect violations of this syntax constraint. Accidental violations
can be minimised by forcing each extended-type link to have only a single arc
role on all the arcs that the extended-type link contains. In practice, this is most relevant to
definition extended-type links, which have four standard arc roles defined:
This is true even though there are additional restrictions
on which definition arcs may apply to which element pairs. The other extended-type links in XBRL each
have only one standard arc role defined in each. |
RH: Revising this rule is necessary due to the use of XDT where arcroles like domain-member and dimension-domain are frequently stored inside one extended link. The rule may still stand for the original 2.1 specified definition links but I don’t see the added value. Propose to scrap the rule.
CH: Ask Walter, Mark G. and Cliff maybe IHR if there is a reason NOT to scrap this rule.
THIS RULE IS REMOVED
|
Each
extended-type link must have a nonempty
role
attribute. XBRL processors treat extended-type links separately when they have different values for the role attribute. This is a consequence of specification section 3.5.3.3 [XBRL],
which indicates that the role attribute must
not be empty and that the standard value for the role attribute
is http://www.xbrl.org/2003/role/link. |
RH: scrap, is a 2.1 specification enforced rule.
YN: Empty attribute allowed? (RH: No, mandatory attributes MUST be equipped with a value = XSD specification).
THIS RULE IS REMOVED
|
Extended-type
links that are not necessarily processed together by consuming applications must have distinct role values. Typical reasons that extended-type links are not be processed together are that the links may be incompatible (such as two alternative presentation formats that cannot be mixed), or that the links may be redundant. This is a consequence of specification sections 3.5.3.3
and 5.2 [XBRL],
which define, respectively, the syntax and semantics of the extended-type
link role attribute. |
RH: I am in doubt, I think there is NO rule in the specification that states that the @role on extended links needs to be unique. With the @href multiple linkbase documents can be addressed and I don’t see why they couldn’t be using the same @role. It involves that the software merges these ELR’s, but so what?
|
Any
role type definition for an extended-type link in a persisting DTS must have a human-readable explanation in its definition
element. In addition to being good practice to document newly
defined roles, the purpose of this rule is to ensure the availability of a
human-readable “label” to appear in taxonomy tools. Users see “Balance Sheet, Order of
Liquidity Format” rather than “http://www.xbrl.org/2003/role/BalanceSheetLiquidity”. This means that in effect the definition
element is required in the roleType element and
its non-empty content should be an explanatory text
string of no more that 50 characters.
Additional description of the processing semantics should
be provided in documentation [TRP]. |
RH: Not preferable anymore. Definitions in XBRL are supported through extended links. This being the exception. The role type definition MUST be supplied, but rather in a generic label linkbase. The <link:definition> node has become optional (2.1 specification defines it as optional). Using a linkbase also provides multiple languages and even references if necessary. Maybe it is wise to have a standard arcrole entered in the LRR for this purpose.
YN: Preferred in generic label link, optional in <link:definition>
Proposed new text:
|
Any
role type definition for an extended-type link in a persisting DTS must have a human-readable explanation In addition to being good practice to document newly
defined roles, the purpose of this rule is to ensure the availability of a
human-readable “label” to appear in taxonomy tools. Users see “Balance Sheet, Order of
Liquidity Format” rather than “http://www.xbrl.org/2003/role/BalanceSheetLiquidity”. This means that a generic label linkbase needs to be
created to be attached to this @role attribute which contains the human
readable text. Suggested is to use the arcrole URI http://www.xbrl.org/2010/arcrole/role-label.
Besides this solution the XBRL specification supports the definition
element in the roleType element. Its non-empty content CAN be an explanatory text string of no more that 50
characters, but the generic label link is preferred. Additional descriptions
of the processing semantics MUST be provided in generic
label or reference links. |
|
The
role URI in a roleType element must be an LRR
approved role or begin with the same scheme and authority parts as the target
namespace of the taxonomy schema where it appears. This limits the potential for accidental merging of
independently created networks of relationships. Only the scheme and authority [RFC2396]
must be the same, not the entire path.
When the URI is a URN [RFC2141],
this rule is interpreted to mean that the NID must be the same. |
RH: Not ‘appears’ but ‘is created’. This means that extensions that create their own ELR’s can never have the @roleURI ‘look’ like an original one.
Proposed new text:
|
The role URI in a roleType element must be an LRR approved role or have a naming convention guaranteeing uniqueness. An example of such naming convention CAN be: All roleType role URI’s are a concatenation of the same scheme and authority parts as the target namespace of the taxonomy schema where it appears, a custom part and ends with the word ‘role’. This limits the
potential for accidental merging of independently created networks of
relationships. Only the scheme and
authority [RFC2396]
must be the same, not the entire path.
When the URI is a URN [RFC2141],
this rule is interpreted to mean that the NID must be the same. |
|
The
role URI in a roleType element should end with
“role” and a human-readable name. In addition to as the constraints on the first part of a
role URI (rule 3.1.11 above),
the last part of the role must have a specified form as well. This rule is not mandatory because not all URI
schemes might support this convention.
When the URI is a URN [RFC2141]
this is interpreted to mean that the NIS should
contain role. |
RH: Do not agree. Why is it important to put so many string format demands on the roleURI? Uniqueness is an argument but is already enforced by 3.1.11 and that should be a concern of the DTS author, not a FRTA prescription. Human readability is solved with a) link:definition and b) generic link. It looks the same as an rule stating that all elements should have the string ’concept’ in their name.
YN: Agree
CH: naming convention for URI’s is all that is meant, and to prevent doubles.
THIS RULE IS REMOVED, ITS CONTENT MERGED IN RULE 3.1.11
|
All arcs whose
source and target both refer to concepts must
specify an order
attribute. This rule universally applies to all arcs in all extended-type links in the calculation, definition and presentation linkbases, and applies to arcs with any arc role, whether standard or custom. This rule ensures that linkbases in taxonomies published conforming to FRTA have a common way of being presented in different tools. It is also meant to apply to any future XBRL modules that introduce new linkbases connecting concepts with each other; it does not apply to the label, reference (or footnote) linkbases. Section 3.5.3.9.6 of XBRL 2.1 Specification indicates that the order attribute is optional, but the order attribute is required in FRTA-compliant taxonomies. Note that each sub-network of relationships and the way it
is displayed to a user may bear no resemblance to any other sub-network. For example, a display in which the
definition essence-alias arcs show each essence item as
the parent of a list of alias items need bear no relationship to presentation
parent-child
or calculation summation-item arcs. |
RH: Nonsense. Definition (2.1, not XDT) links, Generic links. Rule MAY be of interest for presentation and XDT links but that’s it. If the uniform presentation of arcs across different types is really important, the @order should be made mandatory by the SWG.
CH: Order is only interesting is some arcs, If order matters you MUST use the @order, it is about presentation (could be calculation presentations, or domain members in a domain), and it plays a role in the prohibiting of arcs.
Proposed new text:
|
If the presentation order or prohibition of arcs is important, all arcs must specify an order attribute. This rule applies to all arcs in all extended-type links in all linkbases independent from the arcrole. This rule ensures that linkbases in taxonomies published conforming to FRTA have a common way of being presented in different tools. Another reason using an order attribute is that the prohibition of arcs by extenders works on the combined key of linkrole, parent, child, arcrole and @order. If the @order would be missing the prohibition would take place on the default order value one, and on prohibition arc could potentially touch multiple arcs. Examples where the @order would be
useless are the label, reference (or footnote) linkbases. Note that each
sub-network of relationships and the way it is displayed to a user may bear
no resemblance to any other sub-network.
For example, a display in which the definition domain-domain-member arcs show each domain item as the parent of a list of domain
member items need bear no relationship to presentation parent-child or calculation summation-item arcs. |
|
Two
relationships defined by arcs in the same base set with the “use” attribute
having the value “optional”, having concepts as targets and sharing the same
“from” concept should have distinct values for the
“order” attribute. It is desirable for a DTS to have a deterministic ordering among siblings when displayed. This is always possible to ensure even for a DTS that imports two otherwise incompatible DTS’s, by prohibiting any arcs that introduce ambiguous ordering. This rule does not apply to relationships with the use attribute value of prohibited; it also does not apply to relationships between concepts and resource-type elements. Note that this rule applies to relationships, not to
arcs. Therefore, an arc with a “to”
attribute value that is the XLink label of more that one concept would
necessarily violate this rule since its ‘order’ attribute would then apply to
siblings. |
RH: I think that prohibiting arcs just to re issue a new order attribute is a too strong an argument. Does rendering use the @order?
CH: This rule should be in the spec. 2.1. Since its not, it’s in FRTA.
|
All
arc-type elements may have use and priority
attribute values. This is a consequence of specification section 3.5.3.9.7 [XBRL],
which defines how XBRL processors interpret the optional use and priority
attributes. |
RH: is repeating the 2.1 specification, redundant, scrap.
YN: scrap
THIS RULE IS REMOVED
|
All
extended-type, locator-type, arc-type, and resource-type elements may have a title
attribute. XBRL processing ignores the title attribute. The title attribute is intended for use by XLink processors. This is a consequence of specification section 3.3.5.6 [XBRL],
which states that “titles have no XBRL specified semantics.” Section 3.5.3.9.6 applies to extended-type
links, 3.3.5.6 to arcs. |
RH: is repeating the 2.1 specification, redundant, scrap.
YN: scrap
CH: better is to create a rule where this @ should be used for. No semantic meaning in the @title.
Proposed new text (the RULE is
REMOVED):
|
The XLink attributes @title, @show and @actuate MUST NOT be used for semantic meaning aimed at reporters or extenders. XBRL processing ignores these attributes. These attributes are intended for use by XLink processors. This is a consequence of specification section 3.3.5.6 [XBRL],
which states that “titles have no XBRL specified semantics.” Section 3.5.3.9.6 applies to extended-type
links, 3.3.5.6 to arcs. |
|
Taxonomy creators may provide show and actuate attribute
values on linkbase arcs. XBRL processing ignores the show and actuate
attributes. These attributes are intended
for use by XLink processors. |
RH: is repeating the 2.1 specification, redundant, scrap.
CH:
same as @title, no semantic meaning.
THIS
RULE IS REMOVED and replaced with the text in rule 3.1.16
|
[SPEC] |
XBRL Specification 2.1, Recommendation, 31 Dec 2003. http://www.xbrl.org/SpecRecommendations/ |
|
[FRTA] |
Financial Reporting Taxonomies Architecture 1.0, Recommendation, 25
April 2005. http://www.xbrl.org/TaxonomyGuidance/ |
|
Date |
Editor |
Summary |
|
October 2009 |
Hommes |
Draft version 0.1 and 0.2 for review by INT-TA. |
|
|
|
|
|
|
|
|
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may not be modified
in any way, such as by removing the copyright notice or references to XBRL
International or XBRL organizations, except as required to translate it into
languages other than English. Members of XBRL International agree to grant
certain licenses under the XBRL International Intellectual Property Policy
(www.xbrl.org/legal).
This document and the information contained herein is
provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The attention of users of this document is directed to
the possibility that compliance with or adoption of XBRL International
specifications may require use of an invention covered by patent rights. XBRL
International shall not be responsible for identifying patents for which a
license may be required by any XBRL International specification, or for
conducting legal inquiries into the legal validity or scope of those patents
that are brought to its attention. XBRL International specifications are
prospective and advisory only. Prospective users are responsible for protecting
themselves against liability for infringement of patents. XBRL International
takes no position regarding the validity or scope of any intellectual property
or other rights that might be claimed to pertain to the implementation or use
of the technology described in this document or the extent to which any license
under such rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights. Members of XBRL
International agree to grant certain licenses under the XBRL International
Intellectual Property Policy (www.xbrl.org/legal).