Naming Conventions

From XBRLWiki

Revision as of 13:23, 25 October 2012; Hommes (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search

Comment-02 Comment-03

Contents

Folders

Folders are irrelevant to XML but important to control versioning of released files and ownership of these files.

  • Taxonomy files MUST be released as children of a folder.
  • The top level folder of any taxonomy MUST represent the owner of the taxonomy files.

Comment-01

  • The first level of sub folders MUST represent the content of the taxonomy files:
    • dict for metrics, dimensions, domains, members, families and perspectives;
    • fws for frameworks, taxonomies, tables, modules and other concepts that constitute the reporting requirements;
  • The first level of sub folders MAY represent the content of other taxonomy files:
    • ext for models;
    • func for functions for (formula) validations;
  • The second level of sub folders for the fws folder MUST represent the reporting framework in which the taxonomy resides;
  • The third level of sub folders for the reporting framework MUST represent the status of the files within;
  • The fourth level of sub folders for the status of the reporting framework MUST represent the release date of the taxonomy files inside.
  • The fifth level of sub folders for the release date of the taxonomy contains the folders representing the tables, modules and validations;
  • If dates are used to name folders, its notation MUST be: CCYYMMDD (no dashes or other characters).
  • Folder names MUST be in lower case.
  • Folder names MUST NOT use spaces (if a seperator is needed, an underscore is advised)

Comment-04

Comment-05

Example:

  • root
    • dict
    • fws
      • finrep
        • normative
          • 20131201
            • tab
            • mod
            • val
    • ext
    • func

File names

File names are irrelevant to XML but the XBRL adoption of XPointer that addresses @id in named files makes it necessary to have rules on the file names: Picture

Schema file names

  • File names MUST be in lower case;
  • File names MUST NOT be longer than 15 characters;
  • File names MUST NOT use spaces (if a seperator is need an underscore is advised);
  • File name extension '.xsd' MUST be used for schema files;
  • Schema file names MUST represent their technical content according to the following table:
File name Content
tab tables
met metrics
dim dimensions
exp explicit domains
typ typed domains
mem explicit domain members
fam families
pers perspectives
hier member hierarchies
fws frameworks
tax taxonomies
? modules

Comment-06

Comment-07

Linkbase file names

  • File names MUST be in lower case;
  • File name extension '.xml' MUST be used for linkbase files;
  • File names MUST NOT use spaces (if a seperator is needed an underscore is advised);
  • Linkbase file names are created according to the following patterns:

2.1 and generic label linkbase

Label linkbases are broken up per language used. The name of the label linkbase is concatenated from:
{main file}-lab-{lang}.xml
Where:
{main file} = corresponds to the name of the schema or linkbase file where the concept or resource is defined without its extension;
{lang} = corresponds to the ISO 639-1 code of the language (in lower case).

In case of needing any region or country code to identify the language in more detail, the following notation MUST be used:
{main-file}-lab-{lang}-{country}.xml
Where:
{country} = corresponds to the ISO 639-2 code of the region or country (in lower case).

Comment-08

2.1 and generic reference linkbase

{main file}-ref.xml

Comment-08

dimension-domain linkbases

Dimension-domain and dimension-defaultMember relationships are stored in a definition linkbase referenced by the dimensional schema file. The name of the linkbase MUST be dim-def.xml and is placed in the same folder as the dimensional schema file.

domain-member linkbases

{33}-def.xml

Comment-09

table-dimension linkbases

Comment-09

metrics-table linkbases

presentation linkbases

{33}-pre.xml

Comment-10

family-dimension linkbases

pers-pre.xml

calculation linkbases

{33}-cal.xml

Comment-10

formula linkbases

table linkbases

table column and row code linkbase

Some concepts of the taxonomy may refer to codes needed for the codes given to the columns and rows of tables. A linkbase is used to refer to these codes, which are represented in label resources. The name of this linkbase is constructed as follows:
{main file}-lab-codes.xml Where:
{main file} = corresponds to the name of the schema or linkbase file where the concept or resource is defined without its extension;

33 = the name of schema file where the children of the hosted relationships are created.

Comment-13

Example: hier-def.xsd, hier-pre.xsd, hier-cal.xsd

tableGroup table linkbase

Is a generic linkbase where tableGroup as parents MUST contain tables (which are a table:table resource) and MAY contain other tableGroups (which are abstract concepts in the model:tableGroupItem substitutionGroup) as their children. Cycles are not allowed. The custom arc is defined here. The file name is tab-pre.xml.

Comment-19

Namespaces

Namespaces are the unique identifier of a schema file and part of the key on all the content that is created in that schema file. A namespace can be written as an URI or URN. With an URI there is an expectancy that it really identifies the schema. An URN is 'just' a name. A much used practice is to express URI's as URL's without the extension of the actual file it addresses. These URI's are being used as URL's to store the schema file on a server that can be called from software.

A (target)namespace in a schema is often abbreviated with a namespace prefix. This allows for shorthand qualified names to be used inside schema's. Not all XML software can handle schema's that have no namespace prefix assigned to them, and will generate a warning or error. As a consequence two strings are being created and have naming conventions assigned to them.

Target namespace

  • Namespaces MUST be in lower case;
  • Namespaces MUST reflect URI's;
  • Namespaces MUST reflect the actual location (URL) that the schemas are accessable by software (no GUI);

DTS Authors are free to assign any webserver address, however since the URI represents the physical location, the names of folders will automatically form the 'end' of the URI assigned.

Example for the finrep metrics schema at EBA:
xbrl.eba.europa.eu/.../dict/met.xsd
Where the dots represent any folder structure EBA finds appropriate.

Different concepts are stored in different schemas, each carrying their own namespace, location and prefix. The table below shows how their names are constructed.

Namespace prefix

  • Namespace prefix' MUST be in lower case;
  • Namespace prefix' MUST only use characters a-z0-9, -, _;
  • Namespace prefix' MUST be a concatenation of the owner of the schema file, underscore, name of the schema file without the extension which MAY be followed by another underscore and a two letter subdivision;

Examples:
eba_met
eba_mod_xx

See also: Reserved namespaces

Comment-12

Type of concept Location Namespace Prefix
Dimensions {oloc}/dict/dim/dim.xsd {ons}/dict/dim {opre}_dim
Explicit domains {oloc}/dict/dom/exp.xst {ons}/dict/exp {opre}_exp
Families {oloc}/dict/dim/fam.xsd {ons}/dict/fam {opre}_fam
Frameworks {oloc}/fws/fws.xsd {ons}/fws {opre}_fws
Hierarchies {oloc}/dict/dom/{dc}/hier.xsd {ons}/dict/dom/{dc} {opre}_??
Members {oloc}/dict/dom/{dc}/mem.xsd {ons}/dict/dom/{dc} {opre}_{dc}
Metrics {oloc}/dict/met/met.xsd {ons}/dict/met {opre}_met
Perspectives {oloc}/dict/dim/pers.xsd {ons}/dict/pers {opre}_pers
TableGroups {oloc}/fws/{framework}/{normative}/{pub-date}/tab/tab.xsd {ons}/fws/{framework}/{normative}/{pub-date}/tab {opre}_tab
Taxonomies {oloc}/fws/{framework}/{normative}/{pub-date}/tax.xsd {ons}/fws/{framework}/{normative}/{pub-date} {opre}_tax
Typed domains {oloc}/dict/dom/typ.xsd {ons}/dict/typ {opre}_typ

Where:
{oloc} = official location of taxonomy files of the owner of the concepts
{ons} = its base namespace
{opre} = the prefix of its base namespace
{dc} = the code of a domain as used in the DPM
{framework} = the code of the framework in the DPM
{normative} = the term 'optional' or 'normative'
{pub-date} = the date of publication of the files in the subfolders

Example from EBA (metrics):
Location: http://www.eba.europa.eu/eu/fr/xbrl/dict/met/met.xsd
Namespace: http://www.eba.europa.eu/xbrl/dict/met
Prefix: eba_met

Comment-14

Concepts

Local name (@name)

  • The local name of a concept that is a Metric is formed by multiple parts: {Assigned letter}{Periodtype letter}
  • The local name of a concept that is a Dimension is formed by the code used in the data point model; a short sequence of capital case letters (usually two, but it is not limited to two letters).
  • The local name of a concept that is a Family is formed by the numeric code in the data point model, preceded by a lower case 'f'.
  • The local name of a concept that is a Domain is formed by the code used in the data point model; a short sequence of capital case letters (usually two, but it is not limited to two letters).

Comment-18

  • The local name of a concept that is a Explicit domain member is formed by the numeric code in the data point model, preceded by a lower case 'x' EXCEPT when the members are part of a widely accepted standard (like ISO), in this case the @name will represent the international accepted code.
  • The local name of a concept that is TableGroup is formed by the code in the data point model, preceded by a lower case 'tg'.
Concept type Model data type XBRL data type Assigned letter Measure
Metrics Boolean xbrli:booleanItemType b no unit
Metrics Date xbrli:dateItemType d no unit
Metrics Decimal xbrli:decimalItemType p xbrli:pure
Metrics Integer xbrli:integerItemType i xbrli:pure
Metrics Monetary xbrli:monetaryItemType m iso4217:
Metrics Percent num:percentItemType p xbrli:pure
Metrics Text xbrli:stringItemType s no unit
Explicit domain xbrli:qnameItemType e no unit
Typed domain Domain corresponding data type, codification letter and measure.
Dimension xbrli:stringItemType
Families model:familyType
Frameworks model:frameworkType
TableGroups model:tableGroupType
Taxonomies model:taxonomyType
Explicit domain member nonnum:domainItemType

Comment-15 Comment-16

Periodtype letters are:
i = instant
d = duration

Examples:
Monetary instant concept: @name="mi" @id="eba_mi"
Dimension concept @name="CR" @id="eba_CR"
Family concept @name="f3" @id="eba_f3"
Explicit member @name="x1" @id="eba_x1"

Identifier (@id)

The identifier of a concept is constructed as: {opre}_{name}

Where:
{opre} = the prefix of the base namespace of the owner of the concept
{name} = as put in the @name

Types

Codes and enumeration values

Linkroles

URI

  • The URI of perspective linkroles is constructed as: {ons}/role/dict/pers/{code}
  • The URI of hierarchy linkroles for explicit domain members is constructed as: {ons}/role/dict/dom/{dom-code}/{hierarchy-code}
  • The URI of table linkroles is constructed as: {ons}/role/fws/{framework}/{normative}/{pub-date}/tab/{table}


Where:
{ons} = the base namespace of the owner
{code} = the numeric code used in the data point model
{dom-code} = the sequence of capitals representing the domain used in the data point model
{hierarchy-code} = the numeric hierarchy code
{framework} = the code of the framework in the DPM
{normative} = the term 'optional' or 'normative'
{pub-date} = the date of publication of the files in the subfolders
{table} = the code of the table in the DPM

Comment-17

Identifier (@id)

  • The @id on perspective linkroles is constructed as: {opre}_p{code}
  • The @id on hierarchy linkroles for explicit domain member is constructed as: {opre}_r{code}
  • The @id on table linkroles is constructed as: {opre}_t{code}


Where:
{opre} = the prefix if the base namespace of the owner
{code} = the numeric code used in the data point model

Resources

Specials

Personal tools