Naming Conventions

From XBRLWiki

(Difference between revisions)

Jump to: navigation, search

Current revision

Comment-02 Comment-03

1 Folders
2 File names
- 2.1 Schema file names
- 2.2 Linkbase file names
3 Namespaces
- 3.1 Target namespace
- 3.2 Namespace prefix
4 Concepts
- 4.1 Local name (@name)
- 4.2 Identifier (@id)
5 Types
6 Codes and enumeration values
7 Linkroles
- 7.1 URI
- 7.2 Identifier (@id)
8 Resources
9 Specials

[edit]

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

[edit]

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:

[edit]

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	Note
dim.xsd	dimensions	Abstract concepts with @substitutionGroup='dimensionItem', related (2.1) label linkbases and the dimension-domain relationships in a definition linkbase
exp.xsd	explicit domains	Abstract concepts with @type='model:explicitDomainType' and related (2.1) label linkbases
fam.xsd	families	Abstract concepts with @type='model:familyType', related (2.1) label linkbases and parent-child relationships for family-dimension in a presentation linkbase
fws.xsd	frameworks	Abstract concepts with @type='model:frameworkType' and related (2.1) label linkbases
hier.xsd	member hierarchies	Extended linkroles for domain-member, parent-child and (custom) calculation relationships, related (generic) label linkbases and the related definition, presentation and calculation linkbases
mem.xsd	explicit domain members	Abstract concepts with @type='nonnum:domainItemType' and related (2.1) label linkbases
met.xsd	metrics	Non abstract concepts with @substitutionGroup='xbrli:item', @type content pointing to types defined in the 'xbrli:' namespace and its related (2.1) label linkbases
?.xsd	modules
pers.xsd	perspectives	Extended linkroles for parent-child relationships between family and dimension, and related (generic) label linkbases
tab.xsd	tables	Abstract concepts with @type='model:tableGroupType', related (2.1) label linkbases and related custom generic linkbase for tableGroup table relationships
tax.xsd	taxonomies	Abstract concepts with @type='model:taxonomyType' and related (2.1) label linkbases
typ.xsd	typed domains	XML Schema 'raw' elements with 'xs:' derived @type, NO @substitutionGroup content and related (generic) label linkbases

Comment-06 Comment-07

[edit]

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:

File name	Linkbase type	Note
{main file}-lab-{lang}.xml	2.1 and generic label	Label linkbases are broken up per language used
{main-file}-lab-{lang}-{country}.xml	2.1 and generic label	Label linkbases are broken up per language and detail used
{main file}-ref.xml	2.1 and generic reference
dim-def.xml	definition linkbase	Dimension-domain and dimension-defaultMember relationships
{33}-def.xml	definition linkbase	Domain-member relationships
?.xml	? linkbase	Table-dimension relationships
?.xml	? linkbase	Metrics-table relationships through all arcroles only
{33}-pre.xml	presentation linkbase	Parent-child relationships
pers-pre.xml	presentation linkbase	Family-dimension relationships through parent-child arcs
{33}-cal.xml	calculation linkbase	Domain-member relationships through custom arcs
?.xml	formula linkbase
?-rend.xml	table linkbase
{main file}-lab-codes.xml	generic label linkbase	Some concepts of the taxonomy may refer to codes needed for the codes given to the columns and rows of tables (e.g. hier-def.xsd, hier-pre.xsd, hier-cal.xsd)
tab-pre.xml	custom generic linkbase	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

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).
{country} = corresponds to the ISO 639-2 code of the region or country (in lower case).
{33} = the name of schema file where the children of the hosted relationships are created.

Comment-08 Comment-09 Comment-10 Comment-13 Comment-19

[edit]

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.

[edit]

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.

[edit]

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

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

Concepts

[edit]

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"

[edit]

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

[edit]

Types

[edit]

Codes and enumeration values

[edit]

Linkroles

[edit]

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

[edit]

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

[edit]

Resources

The @id on predefined axes resources is constructed as: {opre}_a{code}
The @id on variable axes resources is constructed as: {opre}_a{code}
The @id on coordinate resources is constructed as: {opre}_c{code}
The @id on base item hierarchy reference resources is constructed as: {opre}_h{code}
The @id on dimension hierarchy reference resources is constructed as: {opre}_h{code}
The @id on 2.1 label resources is constructed as: ??
The @id on generic label resources is constructed as: ??
The @id on 2.1 reference resources is constructed as: ??
The @id on generic reference resources is constructed as: ??
The @id on parameter resources is constructed as: ??
The @id on fact variable resources is constructed as: ??
The @id on general variable resources is constructed as: ??
The @id on assertion resources is constructed as: ??

[edit]

Specials

Retrieved from "http://xbrlwiki.info/index.php?title=Naming_Conventions"

Naming Conventions

From XBRLWiki

Current revision

Contents

Folders

File names

Schema file names

Linkbase file names

Namespaces

Target namespace

Namespace prefix

Concepts

Local name (@name)

Identifier (@id)

Types

Codes and enumeration values

Linkroles

URI

Identifier (@id)

Resources

Specials

Views

Personal tools

Navigation

Search

Toolbox

+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-02|Comment-02]]</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-03|Comment-03]]</span>
 == Folders ==
 * 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.
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-01|Comment-01]]</span>
 * The first level of sub folders MUST represent the content of the taxonomy files:
 ** <b>dict</b> for metrics, dimensions, domains, members, families and perspectives;
 * 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 framwork MUST represent the release date of the taxonomy files inside.
+* 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 NOT use spaces (if a seperator is needed, an underscore is advised)
-<span style="background-color:yellow">RH: Do we have a limited list of 'owners' that can be prescribed?</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-04|Comment-04]]</span>
-<span style="background-color:yellow">RH: How do we number the rules uniquely?</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-05|Comment-05]]</span>
-<span style="background-color:yellow">RH: I would like to emphasize that having reasons for each rule prevents a lot of questions. I.e. The reason for folder names to be lower case is to prevent problems between software running on Unix or Microsoft server.</span>
-<span style="background-color:yellow">RH: In a picture supplied in document 'eba-dpm-xbrl-mapping' more subfolders are presented than are explained in the text. Maybe DTS authors are free in creating extra layers within the 'dict' and 'releasedate' folders?</span>
-<span style="background-color:yellow">RH: I do not understand why the dictionary folders are not part of a version or release date. And why it is necessary to have a folder per schema. If there are multiple fam.xsd, met.xsd etcetera there may be a use otherwise a 1:1 has been created.</span>
 Example:
-* dict
+* root
-* fws
+** dict
-** finrep
+** fws
-*** normative
+*** finrep
-**** 20131201
+**** normative
-* ext
+***** 20131201
-* func
+****** 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:
+[[Image:XBRL-Files-Architecture_20121023.JPG|Picture]]
 === Schema file names ===
 * File name extension '.xsd' MUST be used for schema files;
 * Schema file names MUST represent their technical content according to the following table:
+<br/>
 {|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
 |-
 ! File name
 ! Content
+! Note
 |-
-|tab
+|dim.xsd
-|tables
-|-
-|met
-|metrics
-|-
-|dim
 |dimensions
+|Abstract concepts with @substitutionGroup='dimensionItem', related (2.1) label linkbases and the dimension-domain relationships in a definition linkbase
 |-
-|exp
+|exp.xsd
 |explicit domains
+|Abstract concepts with @type='model:explicitDomainType' and related (2.1) label linkbases
 |-
-|typ
+|fam.xsd
-|typed domains
+|families
+|Abstract concepts with @type='model:familyType', related (2.1) label linkbases and parent-child relationships for family-dimension in a presentation linkbase
+|-
+|fws.xsd
+|frameworks
+|Abstract concepts with @type='model:frameworkType' and related (2.1) label linkbases
+|-
+|hier.xsd
+|member hierarchies
+|Extended linkroles for domain-member, parent-child and (custom) calculation relationships, related (generic) label linkbases and the related definition, presentation and calculation linkbases
 |-
-|mem
+|mem.xsd
 |explicit domain members
+|Abstract concepts with @type='nonnum:domainItemType' and related (2.1) label linkbases
 |-
-|fam
+|met.xsd
-|families
+|metrics
+|Non abstract concepts with @substitutionGroup='xbrli:item', @type content pointing to types defined in the 'xbrli:' namespace and its related (2.1) label linkbases
+|-
+|?.xsd
+|modules
 |-
-|pers
+|pers.xsd
 |perspectives
+|Extended linkroles for parent-child relationships between family and dimension, and related (generic) label linkbases
 |-
-|hier
+|tab.xsd
-|member hierarchies
+|tables
+|Abstract concepts with @type='model:tableGroupType', related (2.1) label linkbases and related custom generic linkbase for tableGroup table relationships
 |-
-|fws
+|tax.xsd
-|frameworks
+|taxonomies
+|Abstract concepts with @type='model:taxonomyType' and related (2.1) label linkbases
 |-
-|?
+|typ.xsd
-|modules
+|typed domains
+|XML Schema 'raw' elements with 'xs:' derived @type, NO @substitutionGroup content and related (generic) label linkbases
 |}
-<span style="background-color:yellow">RH: A lot of new (to XBRL) terms are introduced, must they be linked to the definition page?</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-06|Comment-06]]</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-07|Comment-07]]</span>
-<span style="background-color:yellow">RH: Are the new terms agreed upon by the participants or still under review?</span>
 === 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 need an underscore is advised);
+* 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: 11-lab-22.xml
+<br/>
-** 2.1 and generic reference linkbase: 11-ref.xml
+{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
-** dimension-domain linkbases:
+|-
-** domain-member linkbases: 33-def.xml
+! File name
-** table-dimension linkbases:
+! Linkbase type
-** metrics-table linkbases:
+! Note
-** presentation linkbases: 33-pre.xml
+|-
-** calculation linkbases: 33-cal.xml
+|{main file}-lab-{lang}.xml
-** formula linkbases:
+|2.1 and generic label
-** table linkbases:
+|Label linkbases are broken up per language used
+|-
-= the name of the schema file where the building block that requires the label is created (concept, linkrole etc.)<br/>
+|{main-file}-lab-{lang}-{country}.xml
-= a language code according to ISO 639-1 with the restriction to two characters lower case.<br/>
+|2.1 and generic label
-= the name of schema file where the children of the hosted relationships are created. <br/>
+|Label linkbases are broken up per language and detail used
+|-
-<span style="background-color:yellow">RH: There will be no divide in label and reference linkbase(name)s based on the role?</span>
+|{main file}-ref.xml
+|2.1 and generic reference
-<span style="background-color:yellow">RH: The naming convention on D-linkbases is incomplete.</span>
+|-
+|dim-def.xml
+|definition linkbase
+|Dimension-domain and dimension-defaultMember relationships
+|-
+|{33}-def.xml
+|definition linkbase
+|Domain-member relationships
+|-
+|?.xml
+|? linkbase
+|Table-dimension relationships
+|-
+|?.xml
+|? linkbase
+|Metrics-table relationships through all arcroles only
+|-
+|{33}-pre.xml
+|presentation linkbase
+|Parent-child relationships
+|-
+|pers-pre.xml
+|presentation linkbase
+|Family-dimension relationships through parent-child arcs
+|-
+|{33}-cal.xml
+|calculation linkbase
+|Domain-member relationships through custom arcs
+|-
+|?.xml
+|formula linkbase
+|-
+|?-rend.xml
+|table linkbase
+|-
+|{main file}-lab-codes.xml
+|generic label linkbase
+|Some concepts of the taxonomy may refer to codes needed for the codes given to the columns and rows of tables (e.g. hier-def.xsd, hier-pre.xsd, hier-cal.xsd)
+|-
+|tab-pre.xml
+|custom generic linkbase
+|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 [[EXTA_extension_schema|here]]
+|}
+<br/>
+Where:<br/>
+{main file} = corresponds to the name of the schema or linkbase file where the concept or resource is defined without its extension;<br/>
+{lang} = corresponds to the ISO 639-1 code of the language (in lower case).<br/>
+{country} = corresponds to the ISO 639-2 code of the region or country (in lower case).<br/>
+{33} = the name of schema file where the children of the hosted relationships are created. <br/>
-<span style="background-color:yellow">RH: The naming convention on P and C-linkbases forces children to come from the same schema or split linkbases per children origin. Is that the intention or is there a better algorhytm for the naming convention?</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-08|Comment-08]]</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-09|Comment-09]]</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-10|Comment-10]]</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-13|Comment-13]]</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-19|Comment-19]]</span>
 == Namespaces ==
 Example for the finrep metrics schema at EBA:<br/>
-xbrl.eba.europa.eu/.../finrep/20131201/met.xsd<br/>
+xbrl.eba.europa.eu/.../dict/met.xsd<br/>
 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 ===
 eba_met<br/>
 eba_mod_xx
+See also: [[Namespaces|Reserved namespaces]]
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-12|Comment-12]]</span>
+{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
+|-
+!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:<br/>
+{oloc} = official location of taxonomy files of the owner of the concepts<br/>
+{ons} = its base namespace<br/>
+{opre} = the prefix of its base namespace<br/>
+{dc} = the code of a domain as used in the DPM<br/>
+{framework} = the code of the framework in the DPM<br/>
+{normative} = the term 'optional' or 'normative'<br/>
+{pub-date} = the date of publication of the files in the subfolders<br/>
+Example from EBA (metrics):<br/>
+Location: http://www.eba.europa.eu/eu/fr/xbrl/dict/met/met.xsd<br/>
+Namespace: http://www.eba.europa.eu/xbrl/dict/met<br/>
+Prefix: eba_met<br/>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-14|Comment-14]]</span>
 == 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).
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-18|Comment-18]]</span>
+* 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'.
+{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
+|-
+!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
+|}
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-15|Comment-15]]</span>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-16|Comment-16]]</span>
+Periodtype letters are:<br/>
+i = instant<br/>
+d = duration
+Examples:<br/>
+Monetary instant concept: @name="mi" @id="eba_mi"<br/>
+Dimension concept @name="CR" @id="eba_CR"<br/>
+Family concept @name="f3" @id="eba_f3"<br/>
+Explicit member @name="x1" @id="eba_x1"<br/>
+=== Identifier (@id) ===
+The identifier of a concept is constructed as: '''{opre}_{name}'''<br/>
+Where:<br/>
+{opre} = the prefix of the base namespace of the owner of the concept<br/>
+{name} = as put in the @name<br/>
 == 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}
+<br/>
+Where:<br/>
+{ons} = the base namespace of the owner<br/>
+{code} = the numeric code used in the data point model<br/>
+{dom-code} = the sequence of capitals representing the domain used in the data point model<br/>
+{hierarchy-code} = the numeric hierarchy code<br/>
+{framework} = the code of the framework in the DPM<br/>
+{normative} = the term 'optional' or 'normative'<br/>
+{pub-date} = the date of publication of the files in the subfolders<br/>
+{table} = the code of the table in the DPM<br/>
+<span style="background-color:yellow">[[Talk:Naming_Conventions#Comment-17|Comment-17]]</span>
+=== 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}'''
+<br/>
+Where:<br/>
+{opre} = the prefix if the base namespace of the owner<br/>
+{code} = the numeric code used in the data point model<br/>
 == Resources ==
+* The @id on ''predefined axes'' resources is constructed as: '''{opre}_a{code}'''
+* The @id on ''variable axes'' resources is constructed as: '''{opre}_a{code}'''
+* The @id on ''coordinate'' resources is constructed as: '''{opre}_c{code}'''
+* The @id on ''base item hierarchy reference'' resources is constructed as: '''{opre}_h{code}'''
+* The @id on ''dimension hierarchy reference'' resources is constructed as: '''{opre}_h{code}'''
+* The @id on ''2.1 label'' resources is constructed as: ??
+* The @id on ''generic label'' resources is constructed as: ??
+* The @id on ''2.1 reference'' resources is constructed as: ??
+* The @id on ''generic reference'' resources is constructed as: ??
+* The @id on ''parameter'' resources is constructed as: ??
+* The @id on ''fact variable'' resources is constructed as: ??
+* The @id on ''general variable'' resources is constructed as: ??
+* The @id on ''assertion'' resources is constructed as: ??
 == Specials ==