Naming Conventions
From XBRLWiki
| Revision as of 10:27, 2 October 2012 (edit) Hommes (Talk | contribs) (→Folders) ← Previous diff |
Revision as of 10:56, 2 October 2012 (edit) Hommes (Talk | contribs) (→File names) Next diff → |
||
| Line 44: | Line 44: | ||
| 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: | 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: | ||
| + | === Schema file names === | ||
| * File names MUST be in lower case; | * File names MUST be in lower case; | ||
| * File names MUST NOT be longer than 15 characters; | * File names MUST NOT be longer than 15 characters; | ||
| Line 94: | Line 95: | ||
| <span style="background-color:yellow">RH: Are the new terms agreed upon by the participants or still under review?</span> | <span style="background-color:yellow">RH: Are the new terms agreed upon by the participants or still under review?</span> | ||
| + | === Linkbase file names === | ||
| * Linkbase file names are created according to the following patterns: | * Linkbase file names are created according to the following patterns: | ||
| ** 2.1 label linkbase: 11-lab-22.xml | ** 2.1 label linkbase: 11-lab-22.xml | ||
Revision as of 10:56, 2 October 2012
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.
- 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 framwork MUST represent the release date of the taxonomy files inside.
- 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)
RH: Do we have a limited list of 'owners' that can be prescribed?
RH: How do we number the rules uniquely?
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.
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?
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.
Example:
- dict
- fws
- finrep
- normative
- 20131201
- normative
- finrep
- 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:
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;
- File name extension '.xml' MUST be used for linkbase 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 |
| ? | modules |
RH: A lot of new (to XBRL) terms are introduced, must they be linked to the definition page?
RH: Are the new terms agreed upon by the participants or still under review?
Linkbase file names
- Linkbase file names are created according to the following patterns:
- 2.1 label linkbase: 11-lab-22.xml
- generic label linkbase: 11-gla-22.xml
- 2.1 reference linkbase: 11-ref.xml
- dimension-domain linkbases:
- domain-member linkbases: 33-def.xml
- table-dimension linkbases:
- metrics-table linkbases:
- presentation linkbases: 33-pre.xml
- calculation linkbases: 33-cal.xml
- formula linkbases:
- table linkbases:
11 = the name of the schema file where the building block that requires the label is created (concept, linkrole etc.)
22 = a language code according to ISO 639-1 with the restriction to two characters lower case.
33 = the name of schema file where the children of the hosted relationships are created.
RH: There will be no divide in label and reference linkbase(name)s based on the role?
RH: The naming convention on D-linkbases is incomplete.
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?
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/.../finrep/20131201/met.xsd
Where the dots represent any folder structure EBA finds appropriate.
Namespace prefix
- Namespace prefix' MUST be in lower case;
- Namespace prefix' MUST only use characters a-z0-9, -, _;
