Validação e teste da tag <role> e content-type. #391
Conversation
samuelveigarangel
changed the title
| # Verifica se há alguma tag <role> atribuida ao autor. | ||
| if 'role' not in author: | ||
| _result_dict['errors'].append( | ||
| f"The author '{_author_name}' has no <role> tag assigned to him") |
| _content_type = role['content-type'] | ||
| expected_role, expected_content_type = content_type_url[count] | ||
|
|
||
| # Verifica se o par 'role' e 'content type' está presente na lista fornecida. |
There was a problem hiding this comment.
é preferível dicionário no lugar de tuplas pois fica mais explícito e a ordem fica flexível
| self._xmltree = xmltree | ||
| self.article_authors = Authors(self._xmltree) | ||
|
|
||
| def validate_authors_role(self, content_type_url): |
There was a problem hiding this comment.
Colocar comentário para ficar explícito o que é content_type_url
There was a problem hiding this comment.
Entendi que content_type_url seria a lista de valores esperados de content-type e text.
Aí é uma questão de negócio que não deixei claro: os valores esperados eles são como se fossem parâmetros fixos (constantes) do sistema cliente, como se fossem uma "nota de corte" que, ao longo do tempo ela pode mudar, por isso não será uma constante no packtools e sim um parâmetro na função de validação.
Como "nota de corte" significa que todos os documentos ou grupos de documentos serão avaliados diante do mesmo parâmetro.
Ou seja, nesta validação, o valor de content_type_url é a lista de URI e Text atual divulgada no site CRediT.
A validação que ter que ser feita é para cada role, verificar se URI e Text estão presentes em content_type_url.
There was a problem hiding this comment.
Entendi. No caso content_type_url, seria um dict com as chaves term e uri contendo todos os valores obtidos em: https://jats4r.org/credit-taxonomy#table-1-credit-terms-and-urls
|
|
||
| # Verifica se há texto na tag <role> e nenhuma url em content-type. | ||
| if role['text'] and not role['content-type']: | ||
| _result_dict['warnings'].append( |
There was a problem hiding this comment.
O packtools não vai julgar se é warning. No contexto do packtools ou será erro ou será acerto. Na aplicação cliente, vamos balancear a resposta do packtools combinando com outras validações. Porque há prazos de exigência de adoções de determinados elementos / atributos do XML. Então, a exigência de presença ou não vai ficar no nível da aplicação com interface com o usuários e vamos ajustar a gravidade do erro via configuração que o próprio administrador do sistema ficará responsável.
| _result_dict['invalid_content_type'].append( | ||
| f"Author: {_author_name} - Received: {_content_type}, Expected: {expected_content_type}") | ||
| count += 1 | ||
| return _result_dict |
There was a problem hiding this comment.
O retorno deve ser uma lista de dicionários. Dá uma olhada nas validações feitas em outras classes (ainda falta um padrão, pois ainda não encontramos um ideal), mas basicamente há um valor encontrado, valores esperados, resultado, mensagem. Sobre a mensagem, procure informar o problema e sugerir uma solução. Parece óbvio só informar o problema, mas há casos em que só indicar o erro, o usuário produtor do XML não sabe resolver. Então, sugerir a solução por mais óbvia que parecer. Por exemplo:
valor de role ... não corresponde ao esperado
<lista de esperados>. Preencher role com um dos valores esperados.
There was a problem hiding this comment.
@robertatakenaka Faria sentido eu retornar um dict: {'errors': [], 'message_error': []}
Em errors, eu colocaria o erro mais especifico, por exemplo: Not found tag . E em message_errors, eu colocaria a sugestão, por exemplo: The author '{_author_name}' has no tag assigned to him/her. Assign some role to author according to CRedit taxonomy.
There was a problem hiding this comment.
@samuelveigarangel acho que faz mais sentido incluir uma chave como error_type:
[
{...identificação do elemento / atributo que está sendo validado... , 'result': 'error', 'message': '...', 'error_type': ''},
{...identificação do elemento / atributo que está sendo validado... , 'result': 'ok', 'message': '...', },
]Dá uma olhada em alguns comentários que fiz em PR de issues de validação. Em cada validação, é importante destacar qual é o elemento ou atributo do XML que está sendo validado, e o contexto (pois por exemplo há autores em referências bibliográficas (element-citation), então, é sempre bom mencionar o nome do elemento / nome do atributo, pois as pessoas que vão ler os relatórios de validações são aquelas que produzem o XML, então eles "entendem" de XML.
There was a problem hiding this comment.
Ok. Ficou claro @robertatakenaka
…', 'message' e 'credit' como chaves.
| self._xmltree = xmltree | ||
| self.article_authors = Authors(self._xmltree) | ||
|
|
||
| def validate_authors_role(self, credit_terms_and_urls): |
There was a problem hiding this comment.
@samuelveigarangel melhoria: adicionar comentários no padrão https://pandas.pydata.org/docs/development/contributing_docstring.html
| for role in author['role']: | ||
|
|
||
| # Verifica se há role sem texto e sem content-type. | ||
| if not role['text'] and not role['content-type']: |
There was a problem hiding this comment.
@samuelveigarangel as chaves sempre existem?
O que esse PR faz?
Cria validação e teste para a tag e o namespace content-type
Onde a revisão poderia começar?
Por commit
Como este poderia ser testado manualmente?
python setup.py test -s .\tests\sps\validation\test_article_authors.pyAlgum cenário de contexto que queira dar?
N/A
Screenshots
N/A
Quais são tickets relevantes?
#376 #326 #386
Referências
Indique as referências utilizadas para a elaboração do pull request.