This Candidate Recommendation has been approved for publication by the XBRL Standards Board. Candidate Recommendation status indicates that the document meets all relevant requirements and is ready for implementation and testing.
xBRL-CSV Table Constraints are a set of backwards-compatible extensions to xBRL-CSV that enable basic but extremely efficient validation checks.
This specification defines a number of additional validation instructions that sit within xBRL-CSV metadata files, supporting efficient validation of CSV files prior to loading of an XBRL taxonomy and construction of an OIM report model.
This specification does not stipulate a processing model. The design is intended to enable streaming and parallelisation. Most checks can be performed using constant memory, operating on a single row at a time. However, processors remain free to load entire CSV files into memory, or transfer them to persistent storage, if this is convenient for implementing the checks described here or for later operations.
QNames in parenthetical red text after a "MUST" or "MUST NOT" statement prescribe standardised error codes to be used if the preceding condition is violated. "MUST" or "MUST NOT" statements that do not have a prescribed error code are not automatically enforceable, and processors are not required to detect violations.
Prefixes used in this specification are to be interpreted according to the following table:
| Prefix | Namespace URI |
|---|---|
| tc | https://xbrl.org/CR/2025-10-07/tc |
| tcme | https://xbrl.org/CR/2025-10-07/tc/metadataerror |
| tcre | https://xbrl.org/CR/2025-10-07/tc/reporterror |
| xbrl | https://xbrl.org/2021 |
| xs | http://www.w3.org/2001/XMLSchema |
The namespace URI https://xbrl.org/CR/2025-10-07/tc MUST NOT be bound to a prefix other than tc (tcme:invalidNamespacePrefix).
This specification defines three types of validation and two types of processor.
Validation falls into the following categories:
A Table Constraint report validator is a processor that takes an xBRL-CSV report as input and enforces report related constraints defined in this specification.
On encountering a document with the xBRL-CSV document type, a Table Constraint report validator MUST perform Report validation, raising tcre error codes as appropriate.
A Table Constraint metadata validator is a processor that takes an xBRL-CSV report as input and enforces metadata related constraints defined in this specification.
On encountering a document with the xBRL-CSV document type, a Table Constraint metadata validator MUST perform Metadata validation, raising tcme error codes as appropriate.
Some table constraint metadata overlaps with information present in the taxonomy, and it is important that this information is consistent.
This specification does not define specific checks that must be performed by a Table Constraint linter, but instead provides some non-normative, non-exhaustive recommendations for checks that could be performed by such a processor.
Note that Metadata validation and Metadata linting checks are independent of the values in the report. In the common case, where xBRL-CSV metadata is published by an authority collecting xBRL-CSV reports, and re-used for all reports, metadata linting checks only need to be run once and do not need to be repeated for every report.
Table constraint instructions are embedded within xBRL-CSV metadata files, and subject to the same basic JSON syntax restrictions (xbrlce:invalidJSON).
This specification documents the allowed types for all values in JSON metadata. Types are specified as:
Values in the JSON metadata MUST have the JSON type specified with the value constrained as noted above (xbrlce:invalidJSONStructure).
The JSON null value MUST NOT be used unless explicitly specified (tcme:invalidJSONStructure).
In addition, the following constraints apply to JSON metadata (tcme:invalidJSONStructure):
Table constraints are defined by the inclusion of additional properties in xBRL-CSV metadata files. The names of these additional properties are QNames using the tc reserved prefix.
xBRL-CSV metadata files MUST NOT include any tc-prefixed properties other than those defined in this specification, and the defined properties MUST NOT appear within JSON objects other than those defined in this specification (tcme:misplacedOrUnknownProperty).
The xBRL-CSV specification explicitly defines three roles for a column:
This specification uses the following additional definitions:
Note that xBRL-CSV does not prevent a fact column from also providing dimension values for fact columns. Such a hybrid column would not qualify as a dimension column according to this specification.
The xBRL-CSV specification supports table parameters and report parameters. These enable metadata definitions to make use of values defined at either the table or report-level. The parameters used by a table template are not declared explicitly. This specification provides a mechanism for explicitly declaring and constraining the expected parameters for a table template.
Expected parameters can be documented by placing a tc:parameters property as an additional property of a table template object.
The value of the tc:parameters property is a parameters object.
The keys of a parameters object MUST be identifiers (xbrlce:invalidIdentifier). Each key gives the name of the expected parameter.
Each value is a value constraint object.
A parameter that has been defined using this mechanism is known as a defined parameter.
Constraints can be applied to all values in an xBRL-CSV column by placing a tc:constraints property in the additional properties of a column object.
The value of the tc:constraints property is a value constraint object.
The tc:constraints property MUST NOT appear in a comment column definition (tcme:invalidCommentColumnConstraint).
A value constraint object specifies constraints on the values for a column or parameter. It has the following properties:
type (string)optional (boolean)false.nillable (boolean)true.allowedValues (array)allowedPatterns (array)timeZone (boolean)periodType (string)perioddurationType (string)xs:durationlength (non-negative integer)minLength (non-negative integer)maxLength (non-negative integer)minInclusive (string)maxInclusive (string)minExclusive (string)maxExclusive (string)totalDigits (non-negative integer)fractionDigits (non-negative integer)The constrained column or defined parameter associated with a value constraint object is known as the constraint subject.
A value for a constrained column or defined parameter is known as a constrained value. Value constraints for a defined parameter are applied even if the value does not make a contribution to the report model (see xBRL-CSV section 3.2.5).
A table constraint datatype specifies the datatype for values in a column. A table constraint datatype MUST be one of the following (tcme:invalidTypeConstraint):
decimals, indicating that the constraint subject provides a value for the decimals property.All values for a constrained value MUST be valid against type (tcre:invalidValue).
In the case of an XML Schema built-in datatype, validation is as prescribed in the XML Schema specification.
Note that the xs prefix used for XML Schema built-in datatype QNames MUST be declared in the namespaces object, as required by xBRL-CSV.
An xBRL-CSV core dimension is one of the following OIM core dimensions, identified by the specified string:
| Identifier | Dimension |
|---|---|
concept |
Concept core dimension |
entity |
Entity core dimension |
period |
Period core dimension |
unit |
Unit core dimension |
language |
Language core dimension |
The allowed representations for each dimension is as prescribed by the xBRL-CSV specification.
The example below shows a value constraint object on a column object.
"c0090": {
"dimensions": {
"concept": "dict:somedate"
}
"tc:constraints": {
"type": "xs:date"
}
},
In this case, the value is constrained to the xs:date datatype. The value 2024-12-31 appearing in this column would be accepted, but 31/12/2024 would result in a tcre:invalidValue error.
If optional is set to false, then:
Note:
#nil, or the JSON null value in metadata) is considered a value, and satisfies this constraint.#empty in CSV or JSON metadata, or a literal empty string in JSON metadata) is considered a value, and satisfies this constraint.If nillable is set to false, constrained values MUST NOT be nil (specified by #nil or the JSON null value in metadata) (tcre:invalidValue).
If allowedValues is specified then non-nil constrained values MUST be one of the values listed in the allowedValues property (tcre:invalidValue).
This check is performed after applying special value processing, where applicable.
Each item in the allowedValues set MUST conform to type (tcme:illegalAllowedValue).
When type is an XML Schema type, equality is determined according to the rules of XML Schema, and allowedValues behaves equivalently to <xs:enumeration>.
When type is an xBRL-CSV core dimension, equality is determined as defined in OIM 5.1.
The example below shows a value constraint object with the allowedValues property:
"tc:constraints": {
"type": "xs:string",
"allowedValues": [
"RP:x53", "RP:x551", "RP:x56", "RP:x21", "RP:x210" ]
}
A value of RP:x11 for the constraint subject would result in a tcre:invalidValue error.
If allowedPatterns is specified, then non-nil constrained values MUST conform to at least one of the patterns (tcre:invalidValue).
Each pattern is treated as an XML Schema pattern constraint, and is applied to the literal value from the CSV file, after applying special value processing, where applicable.
Note that XML Schema patterns are implicitly anchored to the start and end of the subject string, and also have restrictions on which characters may be escaped using \.
Given the following allowed pattern constraint:
"tc:constraints": {
"type": "xs:string",
"allowedPatterns": [
"[a-z][a-z][a-z]","[A-Z][A-Z][A-Z]"
]
}
aaa and AAA are valid.aaA is invalid.baaa and aaab are invalid.If the timeZone property is specified, type MUST be period or an optionally-timezoned schema type (tcme:unknownTimeZone).
If timeZone is set to true, all values for the constraint subject MUST have a timezone component (tcre:missingTimeZone).
If timeZone is set to false, the values MUST NOT have a timezone component (tcre:unexpectedTimeZone).
If the timeZone property is absent, the presence or absence of a timezone component is unconstrained.
If the periodType property is specified, type MUST be period (tcme:illegalPeriodType).
The periodType property takes one of the following values (tcme:unknownPeriodType), with noted implications for constraint subject value validation (tcre:invalidPeriodType):
year, half, quarter, week, month, dayinstant"tc:constraints": {
"type": "period"
"periodType": "year"
}
In this example, the value 2024 is valid, but 2024H1 will result in tcre:invalidPeriodType.
Other examples for period type constraints:
half:2024H12024quarter: 2024Q12024Q0month:2024-12202410week: 2024W292024day: 2024-12-312024-31-12instant: 2024Q1@end2024W29If the durationType property is specified, the type MUST be xs:duration (tcme:illegalDurationType).
The durationType property takes one of the following values (tcme:unknownDurationType), with noted implications for constrained value validation (tcre:invalidDurationType):
yearMonthdayTimeWhere the length constraint is specified:
type of the column MUST be an XML Schema built-in datatype listed in the applicable facets as applicable for length (tcme:invalidLengthType); andWhere the minLength constraint is specified:
type of the column MUST be an XML Schema built-in datatype listed in the applicable facets as applicable for minLength (tcme:invalidLengthType); andWhere the maxLength constraint is specified:
type of the column MUST be an XML Schema built-in datatype listed in the applicable facets as applicable for maxLength (tcme:invalidLengthType); andWhere the minInclusive constraint is specified:
type of the column MUST be an XML Schema built-in datatype listed in the applicable facets as applicable for minInclusive (tcme:invalidBoundaryType); minInclusive property MUST be a valid value for the specified type (tcre:invalidBoundaryValue); andWhere the maxInclusive constraint is specified:
type of the column MUST be an XML Schema built-in datatype listed in the applicable facets as applicable for maxInclusive (tcme:invalidBoundaryType); maxInclusive property MUST be a valid value for the specified type (tcre:invalidBoundaryValue); andWhere the minExclusive constraint is specified:
type of the column MUST be an XML Schema built-in datatype listed in the applicable facets as applicable for minExclusive (tcme:invalidBoundaryType); minExclusive property MUST be a valid value for the specified type (tcre:invalidBoundaryValue); andWhere the maxExclusive constraint is specified:
type of the column MUST be an XML Schema built-in datatype listed in the applicable facets as applicable for maxExclusive (tcme:invalidBoundaryType); maxExclusive property MUST be a valid value for the specified type (tcre:invalidBoundaryValue); andWhere the totalDigits constraint is specified:
type of the column MUST be an XML Schema built-in datatype listed in the applicable facets as applicable for totalDigits (tcme:invalidDigitsType); andWhere the fractionDigits constraint is specified:
type of the column MUST be an XML Schema built-in datatype listed in the applicable facets as applicable for fractionDigits (tcme:invalidDigitsType); anddecimalsThe constraints that are valid for XML Schema built-in datatype xs:integer are also valid for table constraint datatype decimals.
A Table Constraint linter should apply the following metadata linting checks:
allowedValues should be valid against the relevant taxonomy type or types for the constraint subject.Establishing the taxonomy type or types for values constrained by a value constraint is not always trivial or in some cases possible, as the concept or dimension may be obtained via a property group or parameter.
Constraints across multiple rows may be enforced by including a tc:keys property as an additional property of a table template object.
The value of the tc:keys property is a keys object. It has the following properties:
unique (array)reference (array)sortKey (string)name property of a unique key object appearing in the unique property (tcme:unknownUniqueKey).At least one of unique and reference MUST be specified (tcme:missingKeyProperty).
Each of the key objects has a name property subject to the following constraints:
A unique key enforces uniqueness of values appearing within certain columns.
A unique key is defined by a unique key object.
It has the following properties:
name (string)fields (array)severity (string)error and warning (tcme:invalidKeySeverity). Defaults to error.name MUST be an identifier (xbrlce:invalidIdentifier).
Each entry in the fields array MUST correspond to a constrained column or a defined parameter in the current table template (tcme:illegalUniqueKeyField). If an entry corresponds to both a constrained column and a defined parameter then the type property for both MUST be the same (tcme:columnParameterTypeConflict).
The key value for a row is the ordered set of values for the constrained columns or defined parameters specified in the fields array in that row.
Processors MUST raise tcre:uniqueKeyViolation if the same key value appears in more than one row, across all tables constrained by the same unique key (see Section 4.7.1.2). Equality is established according to the type of the constrained column or defined parameter for each member of the fields array (using XML Schema equality semantics). For the purposes of this check, two absent values are considered equal to each other.
Table Constraint report validators MUST raise tcre:uniqueKeyNilViolation if all values for the unique key fields are nil.
Where multiple templates define a unique key with the same name, a shared unique key is defined. Uniqueness of a shared unique key is enforced across all tables for all templates sharing that unique key.
The following constraints apply to all keys comprising a shared unique key:
severity property ();sortKey for a template, then every key within the shared key MUST also be the sortKey for the template in which it is defined (); fields properties MUST have the same length (); andfields property, the corresponding constrained column or defined parameter MUST have the same type across all keys ().Shared unique keys fulfill the subtype table requirement in a simplified way.
An example of shared unique key is splitting customer into two distinct groups, each having attributes only relevant for that group. Group 1 contains the natural person customers each having an id, a name and a birth date. Group 2 contains the legal entity customers each having an id, a name, a date of incorporation and optionally the VAT rules that apply.
The id is the unique key for both groups. The ids must be unique across both groups.
Multiple tables may be constrained by the same unique key. This occurs where:
Unique key enforcement can be optimised by checking that the rows in a table are sorted according to that key and, in the case that a key is used across multiple tables, the ranges for the key values are disjoint, such that the tables could be combined by concatenation into a single table that is sorted according to that key (see Section 4.7.2.1).
When the sortKey property is present in the tc:keys object for a table template definition, the rows for tables for that template MUST be sorted according to the specified key, as described in this section.
The sort key fields are the fields of the unique key named by the sortKey property.
To establish row ordering, each row is considered in turn. For each row, the value for each of the sort key fields is compared to the corresponding value in the previous row:
Values are compared according to their type:
#nil or JSON null) is considered to be equal to another nil value, and less than any non-nil valuexs:decimal, xs:float, xs:double, xs:boolean, xs:base64Binary, and xs:hex64Binary, values are compared in a manner equivalent to the XPath 3.1 expressions $cur lt $prev and $cur eq $prev, where $cur is the value from the current row, and $prev is the value from the previous rowxs:string, xs:QName and xs:anyURI, values are whitespace normalized and compared lexically according to their unicode codepointsfn:compare($cur, $prev, "http://www.w3.org/2005/xpath-functions/collation/codepoint") where $cur and $prev are the whitespace normalized string representations of the values for the current and previous rows respectivelyZ) and compared as described in Comparison operators on duration, date and time valuesxs:duration:'[^DT]*', or both match the pattern '[^YM]*[DT].*' they are compared according to Two totally ordered subtypes of durationperiod, comparison proceeds according to the semantics for the Period Core Dimension:xs:dateTimexs:dateTimeTo avoid the possibility of tcre:incomparableDurations and tcre:incomparablePeriods errors, template authors are advised to apply timeZone, periodType and durationType constraints.
In the case of cross-table unique keys (see Section 4.7.1.2), row sorting is applied across all tables sharing the same unique key.
In addition to establishing row sorting within each table, for each table A constrained by a unique key there MUST NOT exist another table B constrained by that unique key for which (tcre:keySortViolation):
A reference key checks the values in a column (or combination of columns) against an index corresponding to a unique key.
It is common for reference keys to refer to unique keys in a different table template (hence the database term "foreign key"), but reference keys can also refer to a unique key within the same table template (a "self-referential foreign key").
A reference key is defined by a reference key object. It has the following properties:
name (string)fields (array)referencedKeyName (string)negate (boolean)true, the constraint is inverted so that it passes only if a match is not found in the referenced index. Defaults to false.skipNils (boolean)true, values that are nil are not checked for existence in the key referenced. Defaults to false.severity (string)error and warning (tcme:invalidKeySeverity). Defaults to error.name MUST be an identifier (xbrlce:invalidIdentifier).
Each entry in the fields object MUST correspond to a constrained column or a defined parameter in the current table template (tcme:illegalReferenceKeyField).
The fields array MUST have the same number of items as the fields array of the key specified in referencedKeyName (tcme:invalidReferenceKey), and for each item in the array, the corresponding entry in the referenced key's fields property MUST have the same type as the current item (tcme:inconsistentReferencedFieldType).
The index of values corresponding to the key specified in referencedKeyName is known as the target index. When that name is found in multiple templates, the values from all templates are combined.
The ordered set of values for the parameters and columns in fields for a given row, is known as the local key value.
Reference key validation proceeds as follows for each row in the table template in which at least one of the columns or parameters in the fields object has a value (tcre:referenceKeyViolation):
negate is false, there MUST be a key value in the target index that is equal to the local key value.negate is true, the MUST NOT be a key value in the target index that is equal to the local key value.Equality is established according to the type of the constrained column or defined parameter for each member of the fields array, using XML Schema equality semantics. In order to be considered a match, any field that is absent in the local key value MUST also be absent in the key value for the target index, and vice versa.
To illustrate:
If C and D both don't have a value for a row in BB, no check is done. If C has the value 123 and D has no value, then a check is made to verify that there is a line in table AA with A equal to 123 and B also no value.
The order of the columns in a CSV file may be enforced by adding the columnOrder property to a tableTemplate.
Definition:
columnOrder (array)If columnOrder is defined, then all columns defined for the template MUST be included exactly once and all columns listed MUST be defined in the template (tcme:inconsistentColumnOrderDefinition).
Note that specifying columnOrder does not require the column to be present in the CSV file.
Constraints can be applied to the data tables for a table template by placing a tc:tableConstraints property in the additional properties of a table template object.
minTables (number)maxTables (number)minTableRows (number)maxTableRows (number)The value for these properties MUST be a JSON number, which MUST be a positive integer (xbrlce:invalidJSONStructure).
The number of data tables provided for the table template MUST be:
minTables, if specified (tcre:minTablesViolation).maxTables, if specified (tcre:maxTablesViolation).A fact row is a row in a data table that has a value for at least one fact column .
In each data table for the table template, the number of fact rows MUST be:
tc:minTableRows, if specified (tcre:minTableRowsViolation).tc:maxTableRows, if specified (tcre:maxTableRowsViolation).The functionality provided by minTables overlaps with that provided by the optional field on the table object, but they are intended for use in different reporting situations:
optional works well for report templates that explicitly enumerate the allowed tablesminTables works for situations where the report author is given more freedom over the partitioning of template data across tablesConsider a dimension value supplied through a table parameter. There are cases where it is practical to enumerate all of the dimension values in advance, and other cases where the values can only be supplied by the report author. minTables (in conjunction with minTableRows) allows important facts to be made mandatory even in situations where tables are not enumerated.
This example shows the metadata for a set of CSV files capturing customer data. Every customer must be either a natural person or a legal entity. All natural persons and legal entities must be a customer. If a legal entity customer has country specific VAT rules, the country code provided must exist in countries table.
{
"documentInfo": {
"documentType": "https://xbrl.org/2021/xbrl-csv",
"namespaces": {
"eg": "http://example.com/xbrl-csv/taxonomy-tc",
"lei": "http://standards.iso.org/iso/17442",
"iso4217": "http://www.xbrl.org/2003/iso4217",
"xs": "http://www.w3.org/2001/XMLSchema",
"tc": "https://xbrl.org/CR/2025-10-07/tc"
},
"taxonomy": [
"taxonomy-tc.xsd"
]
},
"tableTemplates": {
"naturalPersonCustomers": {
"columns": {
"customer_id": {
"tc:constraints": {
"type": "xs:int"
}
},
"name": {
"dimensions": {
"concept": "eg:Name"
}
},
"birthDate": {
"dimensions": {
"concept": "eg:birthDate"
}
},
"dimensions": {
"eg:CustomerId": "$customer_id"
},
"tc:keys": {
"unique": [
{
"name": "customerPK",
"fields": [
"customer_id"
]
}
]
}
}
},
"legalEntityCustomers": {
"columns": {
"customer_id": {
"tc:constraints": {
"type": "xs:int"
}
},
"name": {
"dimensions": {
"concept": "eg:Name"
}
},
"incorporationDate": {
"dimensions": {
"concept": "eg:incorporationDate"
}
},
"CountryCodeVAT": {
"dimensions": {
"concept": "eg:countryCode"
},
"tc:constraints": {
"type": "xs:string",
"optional": true
}
}
},
"dimensions": {
"eg:CustomerId": "$customer_id"
},
"tc:keys": {
"unique": [
{
"name": "customerPK",
"fields": [
"customer_id"
]
}
],
"reference": [
{
"name": "LegalEntityCountryToCountriesFK",
"fields": [
"countryCodeVAT"
],
"referencedKeyName": "countriesUK",
"skipNils": true
}
]
}
},
"countries": {
"columns": {
"country_id": {
"tc:constraints": {
"type": "xs:int"
}
},
"countryCode": {
"dimensions": {
"concept": "eg:countryCode"
},
"tc:constraints": {
"type": "xs:string"
}
},
"VATrules": {
"dimensions": {
"concept": "eg:VATrules"
}
}
},
"dimensions": {
"eg:countryID": "country_id"
},
"tc:keys": {
"unique": [
{
"name": "countriesPK",
"fields": [
"country_id"
]
},
{
"name": "countriesUK",
"fields": [
"countryCode"
]
}
]
}
}
},
"tables": {
"natural_persons_data": {
"template": "naturalPersonCustomers",
"url": "natural-person-data.csv"
},
"legal_entity_data": {
"template": "legalEntityCustomers",
"url": "legal-entity-data.csv"
},
"country_data": {
"template": "countries",
"url": "country-data.csv"
}
}
}
This example shows how parameters can be constrained and used in keys.
In the sales table template, the parameter calendar_month, which is used for the period dimension, must be present. Its type is period, which restricts the syntax to values accepted for the period dimension in xBRL-CSV. Additionally, it must be a period covering a single calendar month, using the yyyy-mm shorthand format.
The unique key for the sales table consists of the calendar_month parameter and the product_id column.
{
"documentInfo": {
"documentType": "https://xbrl.org/2021/xbrl-csv",
"namespaces": {
"eg": "http://example.com/xbrl-csv/taxonomy-tc",
"lei": "http://standards.iso.org/iso/17442",
"iso4217": "http://www.xbrl.org/2003/iso4217",
"xs": "http://www.w3.org/2001/XMLSchema",
"tc": "https://xbrl.org/CR/2025-10-07/tc"
},
"taxonomy": [
"taxonomy-tc.xsd"
]
},
"tableTemplates": {
"sales": {
"columns": {
"product_id": {
"tc:constraints": {
"type": "xs:token",
"nillable": false
}
},
"sales": {
"dimensions": {
"concept": "eg:Sales"
}
},
"dimensions": {
"period": "$calendar_month",
"unit": "iso4217:EUR",
"eg:ProductId": "$product_id"
}
},
"tc:parameters": {
"calendar_month": {
"type": "period",
"periodType": "month"
}
},
"tc:keys": {
"unique": [
{
"name": "sales_pk",
"fields": [ "calendar_month", "product_id" ]
}
]
}
},
"tables": {
"salesJan24": {
"url": "salesJan24.csv",
"template": "sales",
"parameters": {
"calendar_month": "2024-01"
}
},
"salesFeb24": {
"url": "salesFeb24.csv",
"template": "sales",
"parameters": {
"calendar_month": "2024-02"
}
},
"salesMar24": {
"url": "salesMar24.csv",
"template": "sales",
"parameters": {
"calendar_month": "2024-03"
}
}
}
}
}
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 (https://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 (https://www.xbrl.org/legal).