fititnt
commented
3 years ago - https://docs.google.com/spreadsheets/d/1gRZ7R1cPKtP3SlVJctN8j6B-ba2-z4YySq2cdcEJ9C8/edit#gid=329563815
- https://proxy.hxlstandard.org/data/edit?dest=data_view&url=https%3A%2F%2Fdocs.google.com%2Fspreadsheets%2Fd%2F1gRZ7R1cPKtP3SlVJctN8j6B-ba2-z4YySq2cdcEJ9C8%2Fedit%23gid%3D329563815
Eu tô super orgulhoso da gambiarra decisão técnica que essa escolha traz. ❤️
Se usar atributos hxl como indicação do que a informação seria já não ajuda na questão de não precisar criar um dicionário separado como TITLE, LICENSE... ele ao menos permite coisas como isto aqui:
SIIIIM! Mesmo sem ter alguma API que traduzisse para português o que '#meta+name' significativa em uma planilha #meta, na própria planilha da para usar regex simples para apenas traduzir para Inglês o que já não está em inglês. Ou seja usar essa abordagem não apenas permitiu ter respostas em diferentes idiomas para mesma informação como permite processamento rápido na própria planilha.
=IF(REGEXMATCH(A3, "i_pt"), GOOGLETRANSLATE(B3, "pt", "en"),B3)
Contexto do problema
No tópico Padrões/convenções mínimos do HXL-CPLP de como uma planilha HXL deveria ter #26 um dos pontos chaves era que, em especial por nós não termos um local como HDX para publicar o resultado final com uma URL que não mudaria, nós definitivamente precisaríamos ter alguma outra estratégia para armazenar a informação. E no fim das contas, o próprio Google Drive pode ser um caminho em especial quando a informação pode ficar completamente publica.
A planilha "README" / Leia-me / "Meta" (atualmente: #meta)
Conforme o #26, um dos mínimos ideias seria que a planilha que explicaria as demais planilhas no mínimo deveria ser um documento HXL válido. Isso na verdade não é difícil fazer (e até poderíamos ocultar alguns campos.
Como o numero campos da planilha Meta (atualmente #meta) poderia ser completamente variável, no fim a ideia de por
#meta+id | #description+labelpoderia servir para por qualquer informação arbitrária. Aqui um exemplo curtoTabela sem +v_zz_hxl`
#meta +id#description+labelEssa abordagem, embora melhor do que nada, tinha alguns problemas
Potencial nova abordagem
Nessa nova abordagem, (embora tecnicamente o cabeçalho poderia continuar sendo
#meta +id), com uso de#meta +id +v_zz_hxldeixamos mais explicito que a coluna inteira teria um significado de uma HXL hashtag + atributo que estaria definida por https://hxlstandard.org/standard/1-1final/dictionary/. O exemplo anterior poderia ser re-escrito como istoTabela com +v_zz_hxl`
#meta +id +v_zz_hxl#description+labelPor que de usar
+v_zz_hxl(e não+v_hxl+hxlEm primeiro lugar, não use
+hxl#meta +id +hxl+v_.O uso de
+v_hxl#meta +id +v_hxlO prefixo
+v_zz_A escolha de "ZZ" como prefixo é baseada no fato de que "ZZ" (assim como alguns outros exemplos, como "XX"), já é usado internacionalmente como um código para elementos definidos por usuário e que estão garantidos que não serão usados para definir um país. Talvez a gente possa usar esse prefixo para outros vocabulários que nem mesmo acreditamos que haveria concordância ou que seria interessante ter nome curto.
Prefixo
+v_xx_O prefixo
+v_xx_("XX") também é listado no ISO_3166-1alpha-2. Esse seria uma alternativa (e que de certa forma faria sentido com a especificação 1.1final, que sugere (quando não é para atributos+termo, mas para#hastags) iniciar hashtags reservadas com `#x. **A escolha de+v_zz_hxlem vez de+v_xx_hxlé meramente opinativa.** Outro ponto é que faria sentido ter mais prefixos no caso de vocabulários definidos por usuários e, se fossemos seguir a lógica dessa página da wikipedia _The following alpha-2 codes can be user-assigned: AA, QM to QZ, XA to XZ, and ZZ._ até mesmo+vaa` poderia ser um prefixo pela logica do ISO_3166-1_alpha-2.Note que a especificação não fala muito sobre como criar os próprios vocabulários, então tudo que é citado neste issue aqui é mais uma padronização interna.