Convenções do HXL-CPLP para adição de metadados padronizados no cabeçalho de documentos HXL

[fititnt]

• Padrões/convenções mínimos do HXL-CPLP de como uma planilha HXL deveria ter #26

---

A especificação do HXL já permite, de forma livre, adicionar qualquer informação (creio que até 20 linhas, antes de efetivamente chegar nas hashtags. Isso é ótimo para quem quer fazer uma conversão rápida de documentos existentes de forma que fiquem parseáveis se prejudicar de forma significativa as planilhas.

Não obstante isso abre espaço para criatividade. Como existem planilhas, como a do CEP dos correios que tem quase 1 milhão de linhas e o HXL proxy suporta (no limite, mas suportar) não é viável querer salvar em Excel apenas para ter uma aba diferente de #meta (metadados). Mesmo que eventualmente tenhamos (ou disponibilizarmos em momentos de crise ativa) um HXL proxy com limites maiores ainda assim é super pertinente que quando, por questões de performance, for necessário ter arquivo único, ainda assim ao menos a licença de uso (como a indicando para uso humanitário apenas) precisa estar lá.

Este tópico aqui é para documentar pontos a respeito disso.

Ideia inicial

No momento estou pensando que esse tipo de planilha deveria

• já na primeira linha começar sempre com "hxl". Isso servidora como fica rápida sobre se deve tentar processar ou não o cabeçalho
• a exemplo da ideia de _(meta-)Vocabulário controlado em HXL: +v_zz_hxl (ex.: #meta+id+v_zz_hxl) quando a coluna usada for uma HXL hashtag + atributos #33_ (que eu tô até orgulhoso da gambiarra solução técnica) a partir da segunda linha os cabeçalhos seriam hashtags hxl completas (hashtag+atributos). O próprio atributo de idioma podeira dar ideia de o que está escrito
• No cancelado as hashtags NÃO podem ter #. Mesmo que o parseador possa tolerar isso, eu imagino poder gerar bugs adicionados

[fititnt]

Creio que em geral tem-se pelo menos duas informações que talvez sejam mais críticas.

• Licença de uso
  • Isso nós mesmos dos CPLP precisaríamos meio logo. o CEP #27 precisaria precisa de indicação sobre uso humanitário apenas.
  • Um bom local que contém códigos parseáveis por máquina seria o https://spdx.org/licenses/. Logo se fossemos sugerir um vocabulário padrão, poderia ser esse.
• Informação confidencial
  • Aqui vem uma questão tensa, mas é melhor aceitar para doer menos e deixar pronto para quem for precisar uma forma de como documentar. Um fato é que eventualmente, as pessoas de organizações vão precisar lidar com dados sensíveis, e alguns deles (por exemplo, os relacionados a dados de processos criminais) precisam de alguma indicação, mesmo que seja para o humano vendo o documento, de que aquilo é extra sensível.
  • Como existem níveis diferentes de informação confidencial, e não existe um local único que tenha um vocabulário entre páíses, creio que a Wikipedia poderia ser um exemplo https://en.wikipedia.org/wiki/Classified_information

[fititnt]

Para o caso de informação confidencial, considerando a logica de usar 'hxl' no inicio do documento, talvez hxl +public seria uma forma de já na primeira linha dar indicação que o padrão do documento não é por padrão com dados sensíveis.

hxl +public |  
meta +discussion+public | https://github.com/HXL-CPLP/forum/issues

Na documentação do 1.1, não tem referencias a questão de privacidade. Aqui tem uma referencia https://groups.google.com/u/1/g/hxlproject/c/N-606LwRz80/m/Q7dq88YzBAAJ em que usariam +sensitive para indicar que uma coluna inteira seria poderia ter dados de acesso restrito.

Creio que caso a gente precise alguma forma de indicar que um documento seria o oposto de acesso publico (Primeira linha: hxl +public) poderiamos usar hxl +sensitive

Sobre de onde eu tirei +public de hxl +public: não parei para revisar. Talvez não seja o melhor termo. Outro ponto é que acesso a lógica de 'acesso publico' não significaria que não teria lincença de uso restrita. Por isso talvez hxl +public geraria confusão.