Descrição do problema
A validação de disponibilidade de dados (packtools/sps/validation/article_data_availability.py, a partir do
modelo DataAvailability em packtools/sps/validation/models/article_data_availability.py) não está
reconhecendo corretamente a declaração quando marcada como <fn fn-type="data-availability"> em <fn-group>,
gerando erro de ausência mesmo quando essa é uma das duas formas previstas pelo SPS.
O SPS 1.10, na seção "Declaração de Disponibilidade de Dados", é explícito:
"A Declaração de Disponibilidade pode ser marcada de duas formas, como uma seção <sec> de <body> ou
<back> ou como uma nota <fn> em <fn-group> de <back>."
Ambas as formas têm atributos próprios documentados:
- Para
<fn>: @fn-type="data-availability" e @specific-use (obrigatórios), com <label> como título.
- Para
<sec>: @sec-type="data-availability" e @specific-use (obrigatórios), com <title>.
A causa raiz exata não foi localizada nesta análise (possivelmente na extração do modelo, que pode não estar
capturando itens marcados via <fn> em todos os cenários), mas o comportamento relatado - erro apenas para a
forma em <fn> - contradiz o SPS.
Passos para reproduzir o problema
- Validar um XML de um
@article-type sujeito à exigência (ex.: research-article) contendo apenas:
<fn-group>
<fn fn-type="data-availability" specific-use="data-available" id="fn1">
<label>Data Availability Statement</label>
<p>...</p>
</fn>
</fn-group>
- Observar que a validação reporta ausência de declaração de disponibilidade de dados, mesmo com a nota
presente e corretamente marcada.
Comportamento esperado
Reconhecer como válidas ambas as formas previstas pelo SPS: <sec sec-type="data-availability"> e
<fn fn-type="data-availability">.
Anexos
Trecho citado a partir do arquivo SPS 1.10_pt.pdf (versão 1.10, última atualização em 22/05/2025), seção
"Declaração de Disponibilidade de Dados".
Classificação (esforço / risco / relevância)
- Esforço: Médio - a lógica de obrigatoriedade por
@article-type já existe; a causa provável está na
extração do modelo (DataAvailability), não é uma regra nova, mas requer localizar a causa raiz exata antes
de corrigir.
- Risco: Médio - toca a validação de um requisito de Open Science já obrigatório para 6 tipos de documento;
a correção não pode regredir o caminho via <sec>, que já funciona.
- Relevância: Alta - a Declaração de Disponibilidade de Dados é obrigatória para 6 tipos de documento
indexáveis; bloquear a forma <fn> impede a publicação de artigos SPS-válidos.
Referências
Descrição do problema
A validação de disponibilidade de dados (
packtools/sps/validation/article_data_availability.py, a partir domodelo
DataAvailabilityempacktools/sps/validation/models/article_data_availability.py) não estáreconhecendo corretamente a declaração quando marcada como
<fn fn-type="data-availability">em<fn-group>,gerando erro de ausência mesmo quando essa é uma das duas formas previstas pelo SPS.
O SPS 1.10, na seção "Declaração de Disponibilidade de Dados", é explícito:
Ambas as formas têm atributos próprios documentados:
<fn>:@fn-type="data-availability"e@specific-use(obrigatórios), com<label>como título.<sec>:@sec-type="data-availability"e@specific-use(obrigatórios), com<title>.A causa raiz exata não foi localizada nesta análise (possivelmente na extração do modelo, que pode não estar
capturando itens marcados via
<fn>em todos os cenários), mas o comportamento relatado - erro apenas para aforma em
<fn>- contradiz o SPS.Passos para reproduzir o problema
@article-typesujeito à exigência (ex.:research-article) contendo apenas:presente e corretamente marcada.
Comportamento esperado
Reconhecer como válidas ambas as formas previstas pelo SPS:
<sec sec-type="data-availability">e<fn fn-type="data-availability">.Anexos
Trecho citado a partir do arquivo
SPS 1.10_pt.pdf(versão 1.10, última atualização em 22/05/2025), seção"Declaração de Disponibilidade de Dados".
Classificação (esforço / risco / relevância)
@article-typejá existe; a causa provável está naextração do modelo (
DataAvailability), não é uma regra nova, mas requer localizar a causa raiz exata antesde corrigir.
a correção não pode regredir o caminho via
<sec>, que já funciona.indexáveis; bloquear a forma
<fn>impede a publicação de artigos SPS-válidos.Referências
packtools/sps/validation/article_data_availability.py,packtools/sps/validation/models/article_data_availability.py