Publicado el marzo 6, 2023 por Editor
El Consejo de Estándares XBRL ha aprobado la publicación de una Recomendación Editada Propuesta del conjunto de especificaciones del Modelo de Información Abierta, que incluye los nuevos formatos xBRL-CSV y xBRL-JSON.
Esta publicación incorpora las correcciones propuestas para los problemas encontrados en la adopción temprana de las nuevas especificaciones. Las especificaciones XBRL siguen un riguroso proceso de estándares para garantizar la interoperabilidad del software que utiliza el estándar. La publicación de correcciones de fe de erratas refleja este compromiso con la calidad y la interoperabilidad, asegurando que se resuelva cualquier texto potencialmente ambiguo o conflictivo en la especificación. Cuando corresponde, los cambios están respaldados por pruebas adicionales de conformance suite, asegurando que todos los procesadores los implementen correctamente.
El estado de Recomendación Editada Propuesta proporciona un período de revisión de seis semanas, después del cual las especificaciones editadas reemplazarán las especificaciones Recomendadas actuales. Las propuestas se pueden encontrar en nuestro sitio de especificaciones.
OIM XBRL-CSV XBRL-JSON XII NOTICIAS
Copyright © 2021, 2022, XBRL International Inc., Todos los derechos reservados.
Esta versión:
Editores:
Paul Warren, XBRL International Inc. <pdw@xbrl.org>
Herm Fischer, Mark V Systems Limited <fischer@markv.com>
Mark Goodhand, CoreFiling <mrg@corefiling.com>
Colaboradores:
Daniel Dracott, CoreFiling <djd@corefiling.com>
Eleanor Joslin, CoreFiling <ejj@corefiling.com>
La circulación de esta propuesta de recomendación editada es ilimitada. Este documento es normativo. Otros documentos pueden reemplazar este documento. Se invita a los destinatarios a enviar comentarios a oim@xbrl.org, y presentar notificación de cualquier derecho de patente pertinente de los que son conscientes y proporcionan apoyo documentación.
En este documento se describe un modelo independiente de la sintaxis para los informes empresariales que cumplen con las especificaciones XBRL v2.1 y XBRL Dimensions v1.0. El modelo es destinado a permitir una transformación fácil y sin pérdidas de un conjunto bien definido de semántica entre una variedad de representaciones sintácticas diferentes, incluyendo la sintaxis XML definida en las especificaciones anteriores.
1. Introducción
1.1. Alcance
1.2. Terminología
1.2.1 Colecciones
1.3 Espacios de nombres y prefijos de espacio de nombres
2. Procesadores
3. Informe XBRL Modelo
3.1 Tipos de datos
3.1.1 Registro de tipos de datos
3.2 Informes
3.3 Hechos
3.4 Dimensiones
3.5 Enlaces
3.5.1 Notas al pie
3.5.1.1 El concepto xbrl:note
4. Contenido prefijado
5.1 Definiciones de igualdad
5.1.1 Igualdad de valor de hecho
5.1.2 Igualdad de valor de dimensión definida por taxonomía
5.1.3 Comparación de URI
5.1.5 Valor canónico del lenguaje
5.2 Definiciones de
6. Hechos duplicados y alternativos
6.1 Duplicados completos
6.2 Duplicados consistentes
6.2.1 Consistencia del valor numérico
6.4 Alternativas multilingües
6.5 Alternativas multiunidad
B Situación de la propiedad intelectual (no normativa)
C Historia del documento (no normativa)
D Fe de erratas Correcciones incorporadas en el presente documento
1. Espacios de nombres y prefijos de espacio de nombres
Valor del lenguaje canónico
Duplicados completos Concepto de componente
Dimensión principal (componente)Procesador conforme Duplicados consistentes
Dimensión principal
Dimensión Hechosduplicados Dimensión principal de la entidad (componente)
Hecho de enumeración Valor de dimensión igual
Propiedad de hecho igual
Hechos iguales Informes iguales Propiedad de hecho equivalente
Hechos equivalentes Informes equivalentes
Hecho (componente) Tipo de datos base de hechos
Hecho Tipo de período Igualdad de valor de hecho Duplicados incoherentes Dimensión principal del idioma (componente)Grupo de vínculos (componente) Lista
Alternativas multilingües Alternativas de varias unidadesNillable
Hecho no numérico Hecho no textual ID de nota dimensión principal (componente)
Hecho numérico Período Dimensión principal (componente)
Contenido prefijado Informe de propiedad (componente)
Igualdad de valor de dimensión definida por taxonomíaHecho
de texto Tipo de datos base de dimensión tipeadaDimensión del núcleo de la unidad (componente) Colección desordenada Validación del fragmento XHTML del procesador conforme
oime:duplicateFactDimension
oime:duplicateFactId
oime:illegalMultiLanguageAlternatives
oime:illegalMultiUnitAlternatives
oime:illegalPureUnit
oime:illegalStandardFootnoteTarget
oime:invalidBaseURL
oime:invalidFactValue
2 oime:invalidLanguage
oime:invalidNoteIDValue
2 oime:invalidTaxonomy
oime:invalidUseOfReservedIdentifier
oime:misplacedDecimalsProperty
oime:misplacedLanguageDimension oime:misplacedNoteFactDimension
2 oime:misplacedNoteIDDimension
oime:missingConceptDimension
oime:missingFactId
oime:missingLanguageForNoteFact
oime:noTaxonomy
oime:unknownConcept
oime:unknownDimension
oime:unsupportedConceptDataType
2 oime:unsupportedDimensionDataType
oime:unusedNoteFact
oime:xhtmlElementInNonDefaultNamespace
Las especificaciones XBRL v2.1 [XBRL 2.1] y XBRL Dimensions v1.0 [DIMENSIONS] definen una sintaxis basada en XML para empresas informes y definiciones de metadatos que lo acompañan, conocidas como taxonomías. Lo es atractivo para trabajar con datos XBRL en una variedad de formatos diferentes, como JSON, bases de datos relacionales y de otro tipo y CSV. Tal uso se ve obstaculizado por la falta de una definición clara de la información que puede considerarse significativo en un informe XBRL, a diferencia de lo que es el detalle sintáctico. Esto conduce a inconsistencias en los datos que se entienden y cómo se entienden. representado, y a menudo a la exposición de detalles sintácticos innecesarios para terminar Usuarios.
Esta especificación define un modelo independiente de la sintaxis para un informe XBRL, que Permite utilizar diferentes formatos sintácticos para representar los mismos datos. El model captura un subconjunto de la información que se puede representar en el XML sintaxis definida por XBRL v2.1, con el fin de proporcionar un modelo simple y portátil.
Este documento proporciona un modelo para un informe XBRL (o XBRL) instancia) que se ajusta al conjunto de especificaciones admitidas. Eso no intenta modelar la información de metadatos definida en un XBRL taxonomía. El Grupo de Trabajo reconoce la importancia de la información taxonómica cuando se trabaja con datos XBRL, pero cree que hay un valor considerable en un modelo que está restringido en alcance al informe XBRL por sí solo y, por lo tanto, tiene elegido para abordar este requisito primero.
Se espera que la información taxonómica forme la base de futuras especificaciones que exponen dicha información en un modelo separado o como capas de Información adicional que complementa el modelo definido en esta especificación.
Las especificaciones soportadas son:
- XBRL v2.1 [XBRL 2.1]
- XBRL Dimensions v1.0 [DIMENSIONES]
- Extensible Enumerations v2.0 [EXTENSIBLE ENUMERATIONS 2.0]
Las palabras clave DEBE, DEBE NOT, REQUERIDO, DEBERÁ, NO DEBERÁ, DEBERÍA, DEBE NOT, RECOMENDADO, PUEDE y OPCIONAL, en esta especificación, deben interpretarse como se describe en [IETF RFC 2119].
El concepto de palabras clave, hecho, nota al pie, y taxonomía, así como los términos nillable y abstracto aplicados a los conceptoss, deben interpretarse como se describe en la especificación XBRL [XBRL 2.1].
Las palabras clave dimensión, hipercubo, dimensión tipada, dimensión explícita y dimensión predeterminada deben interpretarse como se describe en la especificación XBRL Dimensions [DIMENSIONS].
Las palabras clave intervalo de tiempo, hora local y designador de zona deben interpretarse como se define en ISO 8601 [ISO8601].
Esta especificación utiliza los siguientes términos para referirse a: colecciones. El uso de estos términos indica si el pedido y la singularidad de los miembros es significativa bajo el modelo, y por lo tanto si estas propiedades deben conservarse al transformar informes.
Una lista es una secuencia ordenada de miembros. Los miembros pueden repetirse en la lista.
Una colección no ordenada es una colección que puede contener miembros repetidos. El número de veces que aparece cada miembro es significativo, pero el orden entre ellos no lo es. También conocido como bolsa o multi-set.
Un conjunto es una colección desordenada que no contiene miembros repetidos.
1.3 Espacios de nombres y prefijos de espacio de nombres
Se usarán los prefijos de espacio de nombres [Nombres XML] para elementos y atributos en La forma donde es el prefijo de espacio de nombres y es el nombre local. A lo largo de esta especificación, las asignaciones De los prefijos del espacio de nombres a los espacios de nombres reales son coherentes con la Tabla 1.ns:namensname
La columna de prefijo de la Tabla 1 no es normativa. La columna URI del espacio de nombres es normativa.
2. Procesadores
Esta especificación define dos clases de procesadores:
- Un procesador conforme es cualquier software que consume datos que se ajustan al modelo definido en este documento. Un procesador conforme DEBE aplicar las restricciones definidas dentro de esta especificación y generar un error con el código especificado si no se cumple alguna de las restricciones.
- Un procesador compatible de validación es un procesador compatible que aplica adicionalmente todas las restricciones definidas por las especificaciones admitidas y los tipos DTR admitidos para una representación xBRL-XML [xBRL-XML] de los datos en un modelo creado correctamente. Los códigos de error apropiados de esas especificaciones DEBEN generarse si no es posible construir una representación xBRL-XML que satisfaga todas estas restricciones.
El modelo de informe se define como una serie de componentes, cada uno con un conjunto de propiedades con nombre. Estos componentes, y sus propiedades asociadas se definen en las tablas que se muestran a continuación. Los componentes también pueden tener restricciones asociadas con ellos que todos Las instancias de estos componentes deben cumplirse.
El modelo de informe utiliza el sistema de tipos de datos de esquema XML [XML Schema Datatypes] para definir el tipo de datos de los valores. No hace uso del sistema de estructuras de esquemas XML [XML Schema Structures], ya que esto no tiene sentido fuera del contexto de un documento XML.
Los valores del modelo de informe hacen referencia al valor dentro del espacio de valores. La representación léxica no forma parte del modelo.
Cabe señalar que en este documento hay algunas referencias a «Tipos de elementos» XBRL, como . Las referencias a estos tipos de elementos son principalmente para identificar clases de hechos, basados en sus tipos de datos. dtr-type:domainItemType
Los tipos de elementos son técnicamente tipos complejos de esquema XML, ya que contienen definiciones de atributos XML permitidos. Estas definiciones de atributos no son aplicables al modelo de informe y los valores del modelo de informe son sólo requerido para cumplir con las partes de «contenido simple» de estos Datatypes (consulte Definiciones de tipos complejos con Simple contenido [Estructuras de esquema XML]).
3.1.1 Registro de tipos de datos
El Registro de tipos de datos (DTR) [ESTRUCTURA DTR] define un conjunto de tipos de datos adicionales que los procesadores XBRL pueden Opcionalmente soporte. Se hace referencia a varios tipos de DTR directamente por esta especificación, y se denominan tipos DTR compatibles.
Los tipos de DTR admitidos son:
- dtr-type:domainItemType
- dtr-type:noLangTokenItemType
- dtr-type:noLangStringItemType
- dtr-type:prefixedContentItemType
- dtr-type:prefixedContentType
- dtr-type:SQNameType
- dtr-type:SQNameItemType
- dtr-type:SQNamesType
- dtr-type:SQNamesItemType
Algunos tipos de DTR incluyen reglas de validación adicionales como parte de su definición de registro. Los procesadores conformes de validación deben aplicar dichas reglas a los tipos DTR compatibles (consulte la Sección 2).
El componente de nivel superior es un informe.
El tipo de datos de un hecho es el tipo de esquema XML del concepto identificado por la dimensión central del concepto del hecho.
El tipo de datos base de un hecho es el tipo primitivo de esquema XML del que se deriva el tipo de datos del hecho.
Un hecho es nillable si el concepto identificado por la dimensión central del concepto del hecho es nillable.
Un hecho numérico es un hecho con un tipo de datos que se deriva de los tipos de esquema XML xs:decimal, xs:double o xs:float.
Un hecho no numérico es cualquier hecho que no es un hecho numérico.
Un hecho de texto es un hecho con un tipo de datos que se deriva del tipo de esquema XML de , pero que no es uno de los siguientes tipos ni un tipo derivado de uno de ellos: xs:string
- xs:language
- xs:Name
- dtr-type:domainItemType
- dtr-type:noLangTokenItemType
- dtr-type:noLangStringItemType
Un hecho no textual es cualquier hecho que no es un hecho textual.
Un hecho de enumeración es un hecho con una dimensión básica de concepto que identifica un concepto de enumeración. Un hecho de enumeración tiene un valor que es un único nombre expandido o un conjunto de nombres expandidos.
Tenga en cuenta que en las definiciones anteriores, «derivado de» incluye la derivación indirecta a través de tipos intermedios.
La definición de hecho del texto identifica aquellos hechos a los que se aplica la dimensión básica del lenguaje.
Una dimensión es una pieza de información adicional que sirve para identificar de forma única un hecho. Una dimensión puede ser una de las dimensiones principales enumeradas a continuación o una dimensión definida por la taxonomía.
Una dimensión central es una dimensión definida por la especificación XBRL v2.1, a diferencia de las definidas en una taxonomía utilizando la especificación XBRL Dimensions [DIMENSIONS].
3.5.1 Notas al pie
Esta especificación prescribe un comportamiento especial para el tipo de enlace estándar de . Los {hechos de destino} para cualquier grupo de vínculos con este {tipo de enlace} DEBEN tener una dimensión central de concepto de (oime:illegalStandardFootnoteTarget). http://www.xbrl.org/2003/arcrole/fact-footnotexbrl:note
La asignación entre enlaces y notas al pie tal como se define en XBRL v2.1 se describe en xBRL-XML [xBRL-XML].
Esta especificación define el concepto, que se utiliza para representar notas al pie de texto como se define en XBRL v2.1, y para el cual se prescribe un manejo específico en xBRL-XML [xBRL-XML]. El concepto tiene un tipo de datos de . xbrl:notexbrl:notexbrli:stringItemType
El valor del concepto DEBE ser una cadena que contenga una serialización de un fragmento XHTML (oime:invalidXHTMLFragment). La serialización asume un espacio de nombres predeterminado de , y cualquier elemento de ese espacio de nombres DEBE usar el espacio de nombres predeterminado (oime:xhtmlElementInNonDefaultNamespace). xbrl:notehttp://www.w3.org/1999/xhtml
Un fragmento XHTML es un fragmento XML en el que los nodos de elemento de nivel superior se encuentran en el espacio de nombres http://www.w3.org/1999/xhtml.
Hechos con una dimensión central de concepto de: xbrl:note
- DEBE incluirse en la propiedad {target facts} de al menos un grupo de vínculos (oime:unusedNoteFact);
- DEBE tener la dimensión principal del lenguaje (oime:missingLanguageForNoteFact);
- DEBE tener la dimensión principal del identificador de ta (oime:missingNoteIDDimension).
- NO DEBE tener la dimensión principal de entidad o la dimensión de núcleo de período (oime:misplacedNoteFactDimension); y
- NO DEBE tener ninguna dimensión definida por taxonomía (oime:misplacedNoteFactDimension).
Tenga en cuenta que, como hechos de texto, los hechos no pueden tener la propiedad {decimals} o la dimensión de núcleo unitario. xbrl:note
Algunos tipos de datos utilizan prefijos como una notación abreviada para los URI del espacio de nombres. Los valores de estos tipos de datos utilizan un mapa de prefijo a enlaces URI de espacio de nombres que están en el ámbito de la ubicación en la que aparece el valor. Ni los prefijos ni los mapas a los que se refieren forman parte del modelo y, como tal, se requiere un manejo especial de estos valores para garantizar que el modelo contenga los URI a los que se hace referencia en lugar de los prefijos. Los valores para los que esto es necesario se denominan contenido con prefijo.
En un documento XML, la asignación de prefijos a los URI del espacio de nombres se proporciona mediante enlaces de espacio de nombres (consulte [Nombres XML]). Otros formatos basados en este modelo suelen utilizar un mapa de prefijo.
Bajo este modelo, el contenido prefijado es el valor de cualquier hecho o dimensión definida por la taxonomía con un tipo de datos de, o derivado de:
- xs:QName
- xbrli:QNameItemType
- dtr-type:SQNameType
- dtr-type:SQNameItemType
- dtr-type:SQNamesType
- dtr-type:SQNamesItemType
- dtr-type:PrefixedContentType
- dtr-type:PrefixedContentItemType
5 Igualdad y equivalencia
Esta especificación proporciona definiciones separadas de igualdad y equivalencia para hechos e informes. Se puede considerar que los informes equivalentes transmiten la misma información semántica. La definición más estricta de informes iguales requiere además que las propiedades fact {id} sean iguales.
Dos informes, A y B, son iguales bajo este modelo si:
- Para cada hecho en A, hay un hecho igual en B, y viceversa; y
- El componente {taxonomía} de A es igual al componente {taxonomía} de B.
Dos hechos, a y b, son iguales si, para cada propiedad presente en a, hay una propiedad de hecho igual presente en b y viceversa.
Dos propiedades de hecho son iguales si cumplen con el criterio relevante definido a continuación:
- Dos propiedades {id} son iguales si tienen el mismo valor de cadena.
- Dos propiedades {dimensiones}, a y b, son iguales si, para cada dimensión en a, la misma dimensión está presente en b con un valor de dimensión igual y viceversa.
- Dos propiedades {value} son iguales si satisfacen los criterios de igualdad de valor de hecho.
- Dos propiedades {decimales} son iguales si tienen el mismo valor entero.
- Dos propiedades {links}, a y b, son iguales si, para cada grupo de enlaces en a hay un grupo de enlaces en b con las propiedades iguales {group}, {link type} y {target facts}, y viceversa. Dos propiedades {hecho objetivo}, tfa y tfb son iguales si cada hecho en tfa es igual al hecho correspondiente en tfb.
Dos valores de dimensión son iguales si cumplen el criterio pertinente definido a continuación:
- Dos valores de dimensión de núcleo de concepto son iguales si el nombre del espacio de nombres y el nombre local de ambos valores son iguales.
- Dos valores de dimensión de núcleo de entidad son iguales si las propiedades {scheme} e {identifier} tienen los mismos valores de cadena.
- Los valores de dimensión de núcleo de dos períodos son iguales si denotan el mismo intervalo de tiempo definido en ISO 8601.
- Dos valores de dimensión de núcleo unitario son iguales si la colección de medidas de {numeradores} para ambos son iguales, y la propiedad {denominadores} está ausente para ambos o es la misma colección de medidas. Dos medidas son iguales si tienen el mismo nombre de espacio de nombres y nombre local. Tanto {numeradores} como {denominadores} son colecciones desordenadas.
- Dos valores de dimensión principal de idioma son iguales si tienen el mismo valor de idioma canónico.
- Dos valores de dimensión de núcleo de identificador de nota son iguales si tienen el mismo valor de cadena.
- Dos valores de dimensión definidos por taxonomía si satisfacen los criterios de igualdad de valor de dimensión definida por taxonomía.
5.1.1 Igualdad de valor de hecho
Las propiedades {value} de dos hechos son iguales si tienen el mismo tipo de datos y:
- Ambos valores son nulos; o
- Cumplen con el siguiente criterio relevante en función de su tipo de datos:
- Para los hechos de enumeración, los dos valores son el mismo conjunto de nombres expandidos.
- Para el contenido con prefijo, los valores son los mismos después de resolver los prefijos de los URI del espacio de nombres. En el caso de , la colección de valores se trata como una lista. dtr-type:SQNamesItemType
- Para los hechos con un tipo de datos de, o derivado de, los valores son iguales si tienen el mismo valor de lenguaje canónico.xbrli:languageItemType
- Para todos los demás tipos de datos, los valores son iguales si tienen el mismo valor real basado en el tipo de datos de los hechos (véanse también la sección 5.1.3 y la sección 5.1.4).
5.1.2. Igualdad de valor de dimensión definida por taxonomía
Dos valores de dimensión definidos por taxonomía son iguales si tienen el mismo tipo de datos y:
- Ambos valores son nulos; o
- Cumplen con el siguiente criterio relevante en función de su tipo de datos:
- Para el contenido con prefijo, los valores son los mismos después de resolver los prefijos de los URI del espacio de nombres. En el caso de , la colección de valores se trata como una lista. dtr-type:SQNamesType
- Para los valores con un tipo de datos de, o derivado de, los valores son iguales si tienen el mismo valor de lenguaje canónico.xs:language
- Para todos los demás tipos de datos, los valores son iguales si tienen el mismo valor real basado en el tipo de datos de la dimensión (véase también la sección 5.1.3).
Los valores de los tipos de datos de, o derivados de, que son URI relativos no se absolutizan antes de la comparación. Esto significa que dos URI relativos con el mismo valor se considerarán iguales aunque aparezcan en documentos diferentes con diferentes ubicaciones. Esta especificación no especifica dónde deben resolverse los URI relativos que aparecen de hecho y los valores de dimensión definidos por la taxonomía en relación con. xs:anyURI
5.1.4 Comparación de xbrl:nota hechos
XBRL:note los hechos (véase la sección 3.5.1.1) se comparan según su tipo de datos, que se deriva de. Bajo este modelo, el valor es una serialización de un fragmento XHTML. Cabe señalar que al crear un modelo a partir de un informe xBRL-XML [xBRL-XML], hay más de una serialización válida del mismo fragmento XHTML (por ejemplo, los atributos pueden reordenarse), lo que podría llevar a que XHTML equivalente no se considere igual en este modelo. Esto es solo un problema cuando se trabaja con datos derivados de xBRL-XML, ya que otros formatos basados en este modelo deben tratar el valor como una cadena simple. xsd:string
5.1.5 Valor del lenguaje canónico
Un valor de idioma canónico es un espacio en blanco del código de idioma BCP 47 normalizado de acuerdo con los requisitos de xs:language y representado con todas las letras en minúsculas.
5.2 Definiciones de equivalencia
Dos informes, A y B, son equivalentes bajo este modelo si, para cada hecho en A, hay al menos un hecho equivalente en B, y viceversa.
Dos hechos, a y b, son equivalentes sí, para cada propiedad en a, hay una propiedad de hecho equivalente presente en b y viceversa.
Dos propiedades de hecho son equivalentes si cumplen el criterio pertinente de propiedades de hecho iguales con las siguientes modificaciones:
- Dos valores de propiedad {id} siempre se consideran equivalentes (es decir, se ignoran a los efectos de establecer la equivalencia).
- Del mismo modo, cuando se considera la equivalencia de las propiedades {dimensions}, dos dimensiones de núcleo de id de nota siempre se consideran equivalentes.
- Los hechos de las propiedades {hechos de destino} de cada grupo de vínculos de las propiedades {links} solo deben cumplir los requisitos de hechos equivalentes.
6. Hechos duplicados y alternativos
Esta especificación proporciona una serie de definiciones relacionadas con hechos que pueden considerarse duplicados o alternativas para ciertos Propósitos.
Dos hechos, a y b, son hechos duplicados si para cada dimensión en la propiedad {dimensions} de a, la misma dimensión está presente en b con un valor de dimensión igual y viceversa.
Los hechos duplicados son permitidos bajo el modelo, pero los usuarios pueden desear prohibir algunos o Todas las clases de duplicados en aplicaciones específicas.
Los hechos alternativos son hechos que se distinguen solo por el lenguaje o el núcleo unitario. Dimensiones. A diferencia de duplicado hechos, los hechos alternativos son dimensionalmente distintos, pero los usuarios pueden desear restringir su uso, ya que pueden proporcionar Valores alternativos y potencialmente incoherentes para los mismos datos punto.
Ni los duplicados ni los hechos alternativos se consideran un error por esta especificación. Las especificaciones basadas en este modelo PUEDEN prohibir ciertas clases de duplicados y Hechos alternativos. Esta especificación define el código de error estándar, oime:disallowedDuplicateFacts, que PUEDE usarse cuando los hechos duplicados prohibidos están presentes en un informe.
6.1 Duplicados completos
Dos hechos duplicados son duplicados completos si:
- han satisfecho los requisitos de igualdad de valor de hecho; y
- cualquiera de los dos:
- La propiedad {decimals} está ausente de ambos hechos; o
- La propiedad {decimals} tiene el mismo valor entero.
Dos hechos duplicados son duplicados consistentes si son duplicados completos, o:
- son hechos numéricos; y
- Han informado de valores y precisiones que son consistentes con haber sido redondeados a partir de un único valor real, como se describe a continuación.
6.2.1 Consistencia del valor numérico
La consistencia de los valores numéricos se establece considerando el intervalo representado por cada hecho reportado y asegurando que haya superposición entre todos los intervalos. Para este propósito, el intervalo representado por un hecho se toma como un intervalo cerrado, centrado en el valor reportado con un ancho de 10^-N, donde N es el valor de la propiedad {decimals} del hecho, o un intervalo de ancho cero si la propiedad {decimals} es «infinito». Los hechos con el mismo valor {decimales} DEBEN tener el mismo valor numérico para ser considerados consistentes.
Los hechos numéricos que son duplicados completos también se consideran duplicados consistentes.
6.3 Duplicados inconsistentes
Dos hechos duplicados son duplicados inconsistentes si:
- son hechos numéricos pero no son duplicados consistentes; o
- Son hechos no numéricos, pero no satisfacen los requisitos de igualdad de valor de hecho.
Dos hechos, a y b, son alternativas multilingües si:
- Ambos hechos son hechos textuales;
- Para todas las dimensiones, excepto la dimensión central del lenguaje en la propiedad {dimensions} de A, la misma dimensión está presente en B con un valor de dimensión igual y viceversa; y
- Los hechos tienen valores distintos para la dimensión central del lenguaje.
El código de error oime:illegalMultiLanguageAlternatives PUEDE ser utilizado por aplicaciones que prohíben alternativas multilingües.
6.5 Alternativas de unidades múltiples
Dos hechos, a y b, son alternativas de unidades múltiples si:
- Ambos hechos son hechos numéricos;
- Para cada dimensión excepto la dimensión del núcleo unitario en la propiedad {dimensions} de A, la misma dimensión está presente en B con un valor de dimensión igual y viceversa; y
- Los hechos tienen valores distintos para la dimensión del núcleo de la unidad.
El código de error oime:illegalMultiUnitAlternatives PUEDE ser utilizado por aplicaciones que prohíben alternativas de unidades múltiples.
IETF. » BCP47: Etiquetas para identificar idiomas «
XBRL International Inc..«XBRL Dimensions 1.0» Ignacio Hernández-Ros, y Hugh Wallis.
XBRL International Inc. «Registro de tipos de datos – Estructura 1.1″ Mark GoodhandHugh WallisPaul Warren.
XBRL International Inc..«Extensible Enumerations 2.0» Mark Goodhand, y Paul Warren.
IETF (Internet Engineering Task Force).«RFC 2119: Palabras clave para usar en RFC para indicar niveles de requerimiento» Scott Bradner.
Organización Internacional de Normalización. » Representaciones numéricas de fecha y hora de la norma internacional ISO 8601. «
XBRL International Inc. «XBRL Open Information Model Common Definitions» Herm Fischer, Mark Goodhand, y Paul Warren.
XBRL International Inc. «Extensible Business Reporting Language (XBRL) 2.1 incluye erratas corregidas hasta 2013-02-20» Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon y Hugh Wallis.
W3C (World Wide Web Consortium). «Espacios de nombres en XML 1.0 (tercera edición)»
W3C (World Wide Web Consortium). «XML Schema Part 2: Datatypes Second Edition» Paul V. Biron, y Ashok Malhotra.
W3C (World Wide Web Consortium).«XML Schema Part 1: Structures Second Edition» Henry S. Thompson, David Beech, Murray Maloney y Noah Mendelsohn.
XBRL International Inc. «xBRL-XML: XML Mappings for the Open Information Model 1.0» Paul Warren, y Herm Fischer.
Apéndice B Situación de la propiedad intelectual (no normativa)
Este documento y sus traducciones pueden ser copiados y suministrados a otros, y obras derivadas que comentan o de lo contrario, explicarlo o ayudar en su implementación puede ser preparado, copiado, publicado y distribuido, en su totalidad o en parte, sin restricción de ningún tipo, siempre que lo anterior El aviso de derechos de autor y este párrafo se incluyen en todos los copias y obras derivadas. Sin embargo, este documento en sí puede no ser modificado de ninguna manera, como por ejemplo mediante la eliminación de los derechos de autor aviso o referencias a XBRL International o XBRL organizaciones, excepto cuando sea necesario para traducirlo en idiomas distintos del inglés. Miembros de XBRL International aceptar otorgar ciertas licencias bajo XBRL International Política de Propiedad Intelectual (www.xbrl.org/legal).
Este documento y la información contenida en él se proporcionan «TAL CUAL» y XBRL INTERNATIONAL RENUNCIA A TODOS GARANTÍAS, EXPRESAS O IMPLÍCITAS, INCLUYENDO, PERO NO LIMITADO A: CUALQUIER GARANTÍA DE QUE EL USO DE LA INFORMACIÓN AQUÍ CONTENIDA NO INFRINGIR CUALQUIER DERECHO O GARANTÍA IMPLÍCITA DE COMERCIABILIDAD O IDONEIDAD PARA UN PROPÓSITO PARTICULAR.
La atención de los usuarios de este documento se dirige a la posibilidad de que el cumplimiento o la adopción de XBRL Las especificaciones internacionales pueden requerir el uso de una invención cubiertos por derechos de patente. XBRL International no será responsable de identificar las patentes para las que puede ser una licencia requerido por cualquier especificación XBRL International, o para Realizar investigaciones legales sobre la validez legal o el alcance de aquellas patentes que se le señalan. XBRL Las especificaciones internacionales son prospectivas y consultivas solamente. Los usuarios potenciales son responsables de proteger ellos mismos contra la responsabilidad por infracción de patentes. XBRL Internacional no toma posición con respecto a la validez o alcance de cualquier propiedad intelectual u otros derechos que puedan se alegará que pertenece a la aplicación o utilización de la tecnología descrita en este documento o la medida en que cualquier licencia bajo tales derechos podría o no estar disponible; tampoco declara que haya hecho ningún esfuerzo para identificar tales derechos. Los miembros de XBRL International están de acuerdo para otorgar ciertas licencias bajo XBRL International Política de Propiedad Intelectual (www.xbrl.org/legal).
Publicado originalmente: https://www.xbrl.org/news/oim-improvements/