Publicado el 9 de diciembre de 2022 por Editor
La Comisión de Bolsa y Valores de EE. UU. (SEC) ha publicado la última versión de su Interactive Data Test Suite.
El conjunto de pruebas públicas ayuda a los desarrolladores de software a probar sus productos antes de enviarlos a EDGAR. Específicamente, la suite prueba el software para ver si generará informes XBRL que pasen con éxito las pruebas de validación de la SEC y, por lo tanto, serían aceptados.
El conjunto consta de numerosas muestras de datos, incluidos informes, esquemas y bases de enlaces, clasificadas en función de si violan una verificación de validación y, de ser así, cuál y si resultaría en una advertencia o, más gravemente, en un error que causaría rechazo por EDGAR. Estos son gratuitos para que cualquiera los pruebe contra su software.
Acceda al conjunto de pruebas públicas de datos interactivos aquí .
Pruebas DE SOFTWARE de la SEC EE. UU.
Suite de prueba pública de datos interactivos
El propósito del conjunto de pruebas públicas es ayudar a los desarrolladores de software que deben validar los datos interactivos antes de enviarlos a EDGAR. El conjunto de pruebas consta de muchas instancias, esquemas y bases de enlaces de datos interactivos pequeños que se clasifican en función de si violan una verificación de validación y, de ser así, qué verificación de validación violan y si eso resultaría en una advertencia o en un error que hacer que los Datos Interactivos sean rechazados.
Los declarantes que adjuntan archivos de datos interactivos a las presentaciones de EDGAR como archivos adjuntos EX-101 son responsables del cumplimiento de todas las validaciones en el Capítulo 6 del Volumen II del Manual del declarante de EDGAR («el Manual»). La validación automatizada mediante el software de preparación puede hacer que sea más eficiente para los declarantes verificar el cumplimiento antes de enviar sus presentaciones a EDGAR. Nada en este conjunto de pruebas pretende crear nuevos requisitos o cambiar los requisitos existentes para las presentaciones de EDGAR; los solicitantes deben consultar las reglas de la Comisión y el Manual para conocer los requisitos de presentación.
Conjunto de pruebas públicas de datos interactivos
Versión 64d-221128
1. Metas
El propósito del conjunto de pruebas públicas es ayudar a los desarrolladores de software que deben validar los Datos Interactivos antes de su envío a EDGAR. El conjunto de pruebas consta de muchas pequeñas instancias de datos interactivos, esquemas y bases de enlaces que se clasifican en función de si infringen una comprobación de validación y, de ser así, qué comprobación de validación infringen y si eso daría lugar a una advertencia o a un error que provocaría el rechazo de los datos interactivos. Los declarantes que adjuntan Pruebas Interactivas de Datos a las presentaciones de EDGAR son responsables del cumplimiento de todas las validaciones en el Capítulo 6 del Volumen II del Manual del Archivador de EDGAR («el Manual»). La validación automatizada mediante software de preparación puede hacer que sea más eficiente para los solicitantes verificar el cumplimiento antes de enviar sus presentaciones a EDGAR. Nada en este conjunto de pruebas tiene la intención de crear nuevos requisitos o cambiar los requisitos existentes para las presentaciones de EDGAR; los solicitantes deben consultar las normas de la Comisión y el Manual para conocer los requisitos de presentación. La organización del conjunto de pruebas sigue la del capítulo 6 del Manual. El Capítulo 6 consta de subsecciones que detallan una o más validaciones de datos interactivos, y estas subsecciones individuales se agrupan en secciones según el tipo de archivo adjunto (instancia, esquema o base de enlaces) y si las validaciones pueden automatizarse completamente (llamadas secciones de «sintaxis») o si tratan de las relaciones que pueden requerir alguna revisión manual o juicio contable (llamadas secciones «semánticas»).
2. Notación
En este documento, los nombres de ruta de acceso usan barras diagonales, aunque las pruebas funcionan en cualquier sistema operativo.
3. Versiones
El número de versión principal «64d» se refiere a una versión específica del Manual (borrador o de otro tipo) y el número de versión menor «221128» es la fecha de la versión secundaria, formateada como AAMMDD.
4. Instalación
La suite se distribuye como un archivo en formato zip. Extraiga todo el contenido a cualquier ubicación conveniente, conservando las rutas de carpeta. Contiene una carpeta de nivel superior que corresponde a la versión del Manual. Todos los archivos están codificados como formato de transmisión universal de 8 bits (UTF-8) o US ASCII. El sufijo «.xsd» indica un archivo de esquema XML, «.xsl» indica una hoja de estilos XML (XSL) y el sufijo «.xml» indica cualquier otro tipo de archivo XML. No hay ejecutables en el archivo de formato zip a excepción de los archivos XSL 1.0 en las subcarpetas «lib» y «conf». El índice de archivos.htm es un archivo creado para facilitar la navegación de los archivos de prueba; Resalta los archivos de casos de prueba que contienen comentarios que pueden ayudar a los desarrolladores.
5. Biblioteca
La carpeta «lib» contiene datos de referencia y definiciones utilizadas en múltiples ubicaciones de la carpeta conf.
5.1 Archivos DTD y ENT
Una definición de tipo de documento XML (DTD) y tres archivos XML de declaración de entidad (ENT) utilizados para validar el contenido sin escape de bloques de texto y notas al pie XBRL. Un bloque de texto es un elemento XML cuyo tipo es «textBlockItemType» en un espacio de nombres que comienza con «http://xbrl.us/us-gaap/». Una nota al pie XBRL es un elemento XML denominado «nota al pie» en el espacio de nombres «http://www.xbrl.org/2003/linkbase».
5.2 Esquemas y hojas de estilo
Los archivos test.xsd, testcases.xsl y test.xsl se utilizan para validar y ver archivos *-testcase.xml en un navegador, respectivamente. Todos los elementos están en el espacio de nombres http://edgar/2009/conformance.
6. casos de prueba
Un archivo testcase es un archivo XML utilizado por los desarrolladores de software. Los conjuntos de nombres de archivo de archivos que se procesarán juntos y los resultados esperados de ese procesamiento. El archivo XML testcase se transforma normalmente para producir un script de comando de shell; El script de comandos resultante invoca un validador en un archivo en cada variación y almacena el resultado de esa validación. Cuando un validador produce resultados idénticos a los esperados, se dice que es «conforme».
Todos los casos de prueba y sus archivos de prueba están en la carpeta «conf». Los casos de prueba se agrupan por sección con un esquema de código de ordenación que corresponde al número y título de la sección, por ejemplo:
· Sección 6.4 = Carpeta 604-filing-semantics
· Sección 6.5 = Sintaxis de instancia de carpeta 605
Dentro de cada carpeta de sección hay carpetas de subsección, siguiendo un esquema de codificación similar, por ejemplo:
· Sección 6.5.1 = 605-instance-syntax/605-01-identifier-scheme
· Sección 6.19.1 = 619-reference-semantics/619-01/619-01-no-standard-references
Dentro de cada subsección hay un archivo de caso de prueba cuyo nombre tiene el mismo prefijo que la carpeta. Por ejemplo:
· 605-instance-syntax/605-01-entity-identifier-scheme/605-01-entity-identifier-scheme-testcase.xml
Las secciones 6.24 y 6.25 del manual del archivador están anidadas con un nivel adicional de carpetas para distinguir las muestras «buenas» de las «nuevas». Por ejemplo, las variaciones «buenas» de la Sección 6.24.2 se describen aquí:
· 624-rendering/02-contexts/gd/02-contexts-testcase.xml Contiene referencias a instancias de ejemplo, cada una en una subcarpeta diferente:
· 624-rendering/02-contexts/gd/000gd/r02000gd-20081231.xml
· 624-rendering/02-contexts/gd/001gd/r02001gd-20081231.xml
La Sección 5.2.5 del manual del archivador aparece en la sintaxis 525-ix con un nivel adicional de carpetas para distinguir las pruebas que son pruebas de sintaxis XBRL en línea que son «No dependientes de EDGAR» («ned») frente a las que son relevantes para el Manual del archivador de EDGAR («efm») frente a aquellas que no se pueden probar por unidad, pero son «Solo prueba del sistema» («sto»):
· 525-ix-syntax/ned/01-format/i01001gd/i01001gd-20081231.xml
· 525-ix-syntax/efm/00-filing/i0200gd/i0200gd-20081231.xml
· 525-ix-syntax/sto/19-multiio/i19305ng/i19305ng-20181231.xml
La sintaxis del caso de prueba es una modificación de la sintaxis utilizada normalmente por el consorcio XBRL International (http://www.xbrl.org) y, por lo tanto, conserva algunas características que no son significativas para este conjunto de pruebas. El esquema en lib/test.xsd es para validar la sintaxis de cada caso de prueba.
Cada archivo de caso de prueba es XML que se utiliza para programar arneses de prueba y aplicaciones similares. Cada archivo de caso de prueba también tiene una instrucción de procesamiento XML que se refiere a una hoja de estilos XSL 1.0 lib/test.xsl para verla como HTML en un navegador.
La numeración de las secciones del Manual es estable. El número y el significado de las subsecciones no cambiarán, excepto para agregar subsecciones adicionales, o para marcar subsecciones como «eliminadas», «reservadas» o un lenguaje equivalente.
6.1 Elementos requeridos <creador>, <nombre> y <correo electrónico>
Estos elementos nombran a la parte responsable del caso de prueba, que para este conjunto de pruebas es siempre la Oficina de Divulgación Estructurada (OSD) de la SEC.
6.2 Elemento requerido <número>
Por convención, este es el patrón de código de clasificación «6[0-9]{2}- [0-9]{2}», el código de ordenación para una sección como se describió anteriormente. «605-22» significa la sección 6.5.22.
Una convención de numeración adicional utilizada dentro de la sintaxis 525-ix para garantizar que no haya dos variaciones de prueba de nivel de hoja que tengan el mismo nombre, incluso si están en diferentes ramas. Por ejemplo, los casos de prueba en ned/12-references/ coincidirán con i12000gd o i12100ng, mientras que los casos de prueba en efm/12-references coincidirán con i12300gd o i12400ng. De esta manera, los usuarios pueden fusionar fácilmente las carpetas y hacer caso omiso de la distinción efm vs. ned.
6.3 Elemento requerido <nombre>
El esquema restringe esto para que contenga una cadena específica que proporcione una referencia legible para humanos al Manual:
· EDGAR Filer Manual v{versión} 6. {sección}. {subsección} página 6-{página}
6.4 Elemento requerido <descripción>
Este elemento tiene el texto de la sección correspondiente del Manual, pero sólo como referencia; EDGAR Filer Manual Volume II v53 es normativo.
Este elemento también contiene a veces adiciones entre paréntesis como (OBSERVACIÓN …) que indica algún detalle de implementación o comentario relacionado, o un (TODO …) que indica una brecha de cobertura conocida u otra deficiencia en una versión preliminar.
6.5 Elemento de repetición opcional <referencia>
Puede haber cualquier número de elementos de referencia, pero cada uno debe tener @specification de atributo que contenga cualquier cadena útil.
7. El elemento <variación>
Cada caso de prueba contiene una o más variaciones. Cada variación expone solo un aspecto de la validación que se realizará: una variación «no buena» que está destinada a desencadenar exactamente un error de validación o, a veces, una variación «buena» que pretende ilustrar el caso base o un caso extremo.
Todos los elementos secundarios de ese nombre de archivo deben tener contenidos distintos dentro de una sola variación. Por ejemplo, el archivo «this.txt» no puede aparecer como ambos y como.
7.1 Atributo requerido @id de <variación>
Por convención, esto está en el formato «_ [0-9]{3} ((gd)|(ng)| (gw))» en el que «gd» siempre indica una variación buena (válida), «ng» indica una variación no buena (no válida o que desencadena un error) y «gw» indica que esta variación es buena con advertencia. Una variación «gw» pretende ser un ejemplo de una presentación, que será aceptada con advertencias, donde una presentación de tipo «ng» se suspenderá (no se acepta).
Al concatenar el carácter «e», el número de caso de prueba y la parte del @id que se produce después del carácter de subrayado, se obtiene el nombre base de los archivos único para esa variación. Por ejemplo, si el número de prueba es 604-05 y hay una variación llamada «_003gd», entonces habrá archivos de datos con el nombre base e60405003gd.
El número de tres dígitos [0-9]{3} es a menudo una secuencia basada en cero, pero puede tener huecos o algún otro patrón de iteración.
La numeración y el significado de las variaciones individuales dentro de un caso de prueba pueden cambiar de una versión a otra, aunque se espera que esto sea raro.
7.2 Elemento requerido < nombre> de <variación>
Esto contiene texto plano de forma libre, aunque por convención comienza con el número de sección y termina con el token GOOD o NOGOOD. Por ejemplo, estos son los nombres de las variaciones en 605-01-entity-identifier-scheme:
· 6.5.1, El esquema en el ejemplo es http://www.sec.gov/CIK, BUENO
· 6.5.1, Esquema en el ejemplo es http://www.sec.gov, NOGOOD
7.3 Elemento requerido < descripción> de <variación>
Contiene texto sin formato de forma libre; Una vez más, por convención, a menudo duplica el contenido del elemento Name sin el prefijo numérico, y siempre es breve.
7.4 Elemento de repetición opcional <referencia> de <variación>
Puede haber cualquier número de elementos de referencia, pero cada uno debe tener @specification de atributo que contenga cualquier cadena útil.
7.5 Elemento requerido <datos> de <variación>
El elemento de datos agrupa los archivos de datos interactivos en la variación. Esto tiene instancias, bases de enlaces y esquemas. Aunque en principio el conjunto de archivos locales en el conjunto de taxonomía detectable (DTS) de la instancia es detectable desde la instancia, los archivos testcase también sirven como una especie de manifiesto para garantizar que un conjunto de archivos esté completo sin contenido extraño.
El DTS se describe en detalle junto con otras construcciones XBRL en la especificación XBRL 2.1 en: http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html
7.5.1 Elemento de repetición opcional <parámetro> de <datos>
A veces, la validación requiere una entrada externa. Por ejemplo, EDGAR utiliza el número de clave de índice central (CIK) para identificar a los declarantes.
Por ejemplo, las variaciones en el caso de prueba 605-02-entity-identifier-match-cik requieren que el CIK de la presentación se proporcione como parámetro para la validación de una instancia.
7.5.2 Atributo obligatorio @name de <parámetro>
Un QName que es el nombre del parámetro. En este conjunto de pruebas, el contenido de QName debe tener el espacio de nombres vacío.
7.5.3 Atributo requerido @datatype de <parámetro>
Un QName que es el tipo de datos del parámetro, normalmente xs:string.
7.5.4 Atributo obligatorio @value <parámetro>
Una cadena que se convierte al tipo de datos especificado y se pasa al validador.
7.5.5 Nombres, tipos y valores de parámetros actualmente en uso
7.6 Elemento de repetición opcional <primario>
Nombre de archivo de un tipo de archivo que no es de imagen no relacionado con XBRL. Su nombre de archivo puede ser cualquier nombre de archivo compatible con EDGAR que termine en .txt, .htm o .pdf, y está destinado a indicar que el archivo es el documento principal de una presentación EDGAR.
7.6.1 Atributo opcional @docType de <primario>
El tipo de documento (en el sentido de presentación EDGAR) del documento, por ejemplo, «10-K», «485BPOS».
7.7 Elemento requerido <instancia>
El nombre de archivo local de la instancia debe ser un nombre de archivo compatible con EDGAR (menos de 24 caracteres, etc.). Por convención, el nombre tiene el formato siguiente:
E6{sección}{sección}[0-9]{3} ((GD)|( ng))-200(8|9)1231.xml
Por ejemplo, e60501001ng se refiere a una instancia no buena que infringe la sección 6.5.1 del Manual.
Por convención, las instancias que tienen la parte de fecha 20081231 usan la taxonomía DEI 1.0 y aquellas con la parte de fecha 20091231 usan la taxonomía DEI 2009.
El atributo @readMeFirst debe ser «true». Este atributo indica a un script de prueba que es el archivo de instancia que abre primero el validador que se está probando.
7.9 Elemento de repetición opcional <linkbase>
Cada variación tiene bases de enlaces nombradas usando la misma convención de nomenclatura que la instancia.
Muchas variaciones de casos de prueba tienen un conjunto de bases de enlaces comunes denominadas edgar-20081231_*. * o edgar-20091231_*.*. Los archivos linkbase con el mismo nombre «EDGAR-» difieren de una carpeta a otra.
7.10 Elemento de repetición requerido <esquema>
Cada variación tiene al menos un esquema con su propio conjunto de bases de enlaces nombradas con la misma convención de nomenclatura que la instancia.
Por lo general, una variación tiene exactamente un esquema. En raras ocasiones, en la sección 608-schema-syntax o en otro lugar, la naturaleza del caso de prueba puede requerir más de un esquema.
Muchas variaciones de casos de prueba tienen un conjunto de esquemas comunes denominados edgar-20081231.xsd, edgar-20091231.xsd o edgar-20111231.xsd. Los archivos «EDGAR-» con nombres idénticos pueden diferir de una carpeta a otra.
7.11 Elemento de repetición opcional <exposición>
Nombre de archivo de un tipo de archivo que no es de imagen no relacionado con XBRL. Su nombre de archivo puede ser cualquier nombre de archivo compatible con EDGAR que termine en .txt, .htm o .pdf, y está destinado a indicar que el archivo es un documento no primario de una presentación EDGAR.
Publicado originalmente: https://www.xbrl.org/news/sec-publishes-interactive-data-test-suite/