<\/a><\/noindex>Sob essa perspectiva, h\u00e1 uma maneira simples de verificar o qu\u00e3o bem um esquema XML foi feito. Vamos pegar como exemplo um documento no esquema proposto e remover todas as tags e atributos. Se o que sobrar n\u00e3o fizer sentido (ou se sobrar uma linha vazia), ent\u00e3o ou seu esquema est\u00e1 mal constru\u00eddo, ou voc\u00ea simplesmente n\u00e3o deveria ter usado XML.<\/p>\n
A seguir, vou apresentar alguns dos exemplos mais comuns de esquemas mal constru\u00eddos.<\/p>\n
<\/code><\/pre>\n\nAqui vemos um exemplo de uma tentativa infundada e estranha (embora bastante comum) de expressar um dicion\u00e1rio simples \"chave-valor\" em XML. Se removermos todas as tags e atributos, sobrar\u00e3o uma linha vazia. Essencialmente, este documento representa, por mais absurdo que pare\u00e7a, uma anota\u00e7\u00e3o sem\u00e2ntica de uma linha vazia.<\/p>\n
<root name=\"John\" city=\"London\" \/><\/code><\/pre>\n\nPior ainda, n\u00e3o estamos apenas lidando com uma anota\u00e7\u00e3o sem\u00e2ntica de uma linha vazia como uma maneira extravagante de expressar um dicion\u00e1rio \u2014 desta vez, o 'dicion\u00e1rio' est\u00e1 diretamente codificado como atributos do elemento raiz. Como resultado, o conjunto de nomes de atributos definido no elemento torna-se indefinido e din\u00e2mico. Al\u00e9m disso, fica claro que tudo o que o autor realmente queria expressar \u00e9 uma simples sintaxe de 'chave-valor', mas, em vez disso, ele adotou uma decis\u00e3o absolutamente estranha de aplicar XML, for\u00e7ando o uso de um \u00fanico elemento vazio simplesmente como um prefixo para usar a sintaxe de atributos. E esse tipo de esquema aparece com frequ\u00eancia para mim.<\/p>\n
John\n London<\/code><\/pre>\n\nIsso j\u00e1 \u00e9 um pouco melhor, mas agora as chaves, por alguma raz\u00e3o, s\u00e3o metadados e os valores n\u00e3o. Uma vis\u00e3o bastante estranha sobre dicion\u00e1rios. Se voc\u00ea remover todas as tags e atributos, metade da informa\u00e7\u00e3o se perder\u00e1.<\/p>\n
A express\u00e3o correta de um dicion\u00e1rio em XML seria mais ou menos assim:<\/p>\n
Name\n John\n \n \n City\n London<\/code><\/pre>\n\nMas se as pessoas tomaram a estranha decis\u00e3o de aplicar XML como formato de dados e depois usar isso para organizar o dicion\u00e1rio, elas devem entender que o que est\u00e3o fazendo \u00e9 inadequado e inconveniente. Al\u00e9m disso, projetistas frequentemente escolhem XML de forma errada para criar suas aplica\u00e7\u00f5es. Mas ainda mais comum \u00e9 agravarem a situa\u00e7\u00e3o com uma aplica\u00e7\u00e3o sem sentido do XML em uma das formas descritas acima, ignorando o fato de que o XML simplesmente n\u00e3o \u00e9 adequado para isso.<\/p>\n
Qual \u00e9 o pior esquema XML?<\/b> A prop\u00f3sito, o pr\u00eamio por o pior esquema XML que j\u00e1 vi,<\/i> vai para o formato de arquivo de configura\u00e7\u00e3o de aloca\u00e7\u00e3o autom\u00e1tica de recursos para os telefones IP da Polycom. Esses arquivos exigem o download de arquivos XML a partir de solicita\u00e7\u00f5es TFTP, que... Enfim, aqui est\u00e1 um trecho de um desses arquivos:<\/p>\n<softkey\n softkey.feature.directories=\"0\"\n softkey.feature.buddies=\"0\"\n softkey.feature.forward=\"0\"\n softkey.feature.meetnow=\"0\"\n softkey.feature.redial=\"1\"\n softkey.feature.search=\"1\"\n\n softkey.1.enable=\"1\"\n softkey.1.use.idle=\"1\"\n softkey.1.label=\"Foo\"\n softkey.1.insert=\"1\"\n softkey.1.action=\"...\"\n\n softkey.2.enable=\"1\"\n softkey.2.use.idle=\"1\"\n softkey.2.label=\"Bar\"\n softkey.2.insert=\"2\"\n softkey.2.action=\"...\" \/><\/code><\/pre>\n\nIsso n\u00e3o \u00e9 uma piada infeliz de algu\u00e9m. E n\u00e3o \u00e9 uma inven\u00e7\u00e3o minha:<\/p>\n
\nos elementos s\u00e3o usados simplesmente como prefixos para anexar atributos, que por si mesmos t\u00eam nomes hier\u00e1rquicos.\n<\/li>\n Se voc\u00ea precisar atribuir valores a v\u00e1rias inst\u00e2ncias de um determinado tipo de registro, ser\u00e1 necess\u00e1rio usar nomes de atributos, que possuem \u00edndices.<\/i>.\n<\/li>\nAl\u00e9m disso, os atributos que come\u00e7am com softkey.<\/code>, devem ser colocados em elementos <softkey\/><\/code>, atributos que come\u00e7am com feature.<\/code>, devem ser colocados em elementos <feature\/><\/code> , etc., apesar de parecer completamente desnecess\u00e1rio e, \u00e0 primeira vista, sem sentido.\n<\/li>\nE, finalmente, se voc\u00ea esperava que o primeiro componente do nome do atributo sempre correspondesse ao nome do elemento \u2014 nada disso! Por exemplo, os atributos up.<\/code> devem ser anexados a <userpreferences\/><\/code>. A ordem de anexa\u00e7\u00e3o dos nomes dos atributos aos elementos \u00e9 aleat\u00f3ria, praticamente totalmente.\n<\/li>\n<\/ul>\n\nDocumentos ou dados.<\/b>De vez em quando, algu\u00e9m faz coisas absolutamente estranhas, tentando comparar XML e JSON, \u2014 mostrando, assim, que n\u00e3o entende nenhum dos dois. XML \u00e9 uma linguagem de marca\u00e7\u00e3o de documentos. JSON, por outro lado, \u00e9 um formato de dados estruturados, ent\u00e3o compar\u00e1-los entre si \u00e9 como tentar comparar coisas quentes com coisas macias.<\/p>\n
Entender isso ajudar\u00e1 a esclarecer o conceito de diferen\u00e7a entre documentos e dados.<\/i>Como analogia, XML pode ser visto como um documento leg\u00edvel por m\u00e1quina. Embora seja destinado \u00e0 leitura por m\u00e1quina, metaforicamente se refere a documentos, e nesse sentido \u00e9 compar\u00e1vel a documentos em formato PDF, que muitas vezes n\u00e3o s\u00e3o leg\u00edveis por m\u00e1quina. <\/p>\n
Por exemplo, em XML a ordem dos elementos \u00e9 significativa. J\u00e1 em JSON, a ordem de pares \"chave-valor\" dentro de objetos n\u00e3o tem significado e n\u00e3o \u00e9 definida. Se voc\u00ea deseja obter um dicion\u00e1rio n\u00e3o ordenado de pares \"chave-valor\", a ordem real em que os elementos aparecem neste arquivo n\u00e3o importa. Mas voc\u00ea pode formar muitos documentos diferentes a partir desses dados, pois em um documento h\u00e1 uma certa ordem. Metaforicamente, isso \u00e9 an\u00e1logo a um documento em papel, embora n\u00e3o tenha dimens\u00f5es f\u00edsicas, ao contr\u00e1rio de uma impress\u00e3o ou de um arquivo PDF.<\/i>, pois h\u00e1 uma ordem espec\u00edfica no documento. Metaforicamente, isso \u00e9 an\u00e1logo a um documento em papel, embora n\u00e3o tenha dimens\u00f5es f\u00edsicas, ao contr\u00e1rio de uma impress\u00e3o ou arquivo PDF.<\/p>\n
No meu exemplo de representa\u00e7\u00e3o correta de um dicion\u00e1rio em XML, a ordem dos elementos no dicion\u00e1rio \u00e9 mostrada, ao contr\u00e1rio da representa\u00e7\u00e3o em JSON. N\u00e3o posso ignorar essa ordem: tal linearidade \u00e9 intr\u00ednseca ao modelo de documentos e ao formato XML. Algu\u00e9m ao interpretar este documento XML pode decidir ignorar a ordem, mas discutir isso n\u00e3o faz sentido, pois essa quest\u00e3o vai al\u00e9m da discuss\u00e3o do pr\u00f3prio formato. Al\u00e9m disso, se o documento for tornado visualiz\u00e1vel em um navegador, anexando a ele uma folha de estilo em cascata, ser\u00e1 poss\u00edvel ver que os elementos do dicion\u00e1rio seguem uma certa ordem, e de nenhuma outra forma.<\/p>\n
Em outras palavras, o dicion\u00e1rio (fragmento de dados estruturados) pode ser transformado em n<\/i> diversos documentos poss\u00edveis (em formato XML, PDF, em papel, etc.), onde n<\/i> \u2014 o n\u00famero de combina\u00e7\u00f5es poss\u00edveis de elementos no dicion\u00e1rio, e isso sem levar em conta outras vari\u00e1veis poss\u00edveis.<\/p>\n
Ao mesmo tempo, isso tamb\u00e9m implica que se voc\u00ea deseja transmitir apenas dados, usar um documento leg\u00edvel por m\u00e1quina n\u00e3o ser\u00e1 eficaz. Ele utiliza um modelo que, nesse caso, \u00e9 desnecess\u00e1rio e apenas atrapalhar\u00e1. Al\u00e9m disso, para extrair os dados originais, ser\u00e1 necess\u00e1rio escrever um programa. Dificilmente faz sentido usar XML para algo que, em determinado est\u00e1gio, n\u00e3o ser\u00e1 formatado como um documento (digamos, por meio de CSS ou XSLT, ou ambos), pois essa \u00e9 a principal (se n\u00e3o a \u00fanica) raz\u00e3o para seguir o modelo de documento.<\/p>\n
Al\u00e9m disso, uma vez que em XML n\u00e3o existe o conceito de n\u00fameros (ou express\u00f5es booleanas, ou outros tipos de dados), todos os n\u00fameros apresentados nesse formato s\u00e3o considerados apenas texto adicional. Para extrair dados, \u00e9 necess\u00e1rio conhecer o esquema e sua rela\u00e7\u00e3o com os dados correspondentes. Tamb\u00e9m \u00e9 preciso saber, com base no contexto, quando um determinado elemento de texto representa um n\u00famero, e este deve ser convertido em um n\u00famero, e assim por diante.<\/p>\n
Assim, o processo de extra\u00e7\u00e3o de dados de documentos XML n\u00e3o difere muito do processo de reconhecimento de documentos escaneados, que cont\u00eam, por exemplo, tabelas que formam v\u00e1rias p\u00e1ginas de dados num\u00e9ricos. Sim, \u00e9 poss\u00edvel fazer isso, mas n\u00e3o \u00e9 o caminho mais otimizado \u2014 a menos que seja um \u00faltimo recurso, quando n\u00e3o h\u00e1 outras op\u00e7\u00f5es. Uma solu\u00e7\u00e3o mais sensata seria simplesmente encontrar uma c\u00f3pia digital dos dados originais, n\u00e3o integrados no modelo do documento, onde os dados est\u00e3o combinados com sua representa\u00e7\u00e3o textual espec\u00edfica.<\/p>\n
Isso n\u00e3o me surpreende, pois o XML \u00e9 popular nos neg\u00f3cios. A raz\u00e3o para isso \u00e9 que o formato de documentos (em papel) \u00e9 claro e familiar para as empresas, que desejam continuar utilizando um modelo conhecido e compreens\u00edvel. Pelo mesmo motivo, os neg\u00f3cios frequentemente usam documentos em PDF em vez de formatos mais amig\u00e1veis ao processamento autom\u00e1tico - porque ainda est\u00e3o atrelados ao conceito de p\u00e1gina impressa com um tamanho f\u00edsico definido. Isso se aplica mesmo a documentos que provavelmente nunca ser\u00e3o impressos (por exemplo, um arquivo PDF de uma documenta\u00e7\u00e3o de registro com 8000 p\u00e1ginas). Sob essa perspectiva, o uso de XML nos neg\u00f3cios \u00e9, essencialmente, uma manifesta\u00e7\u00e3o de skeuomorfismo. As pessoas entendem a ideia metaf\u00f3rica de uma p\u00e1gina impressa de tamanho limitado e sabem como criar processos de neg\u00f3cios baseados em documentos impressos. Se esse \u00e9 seu ponto de refer\u00eancia, documentos sem um tamanho f\u00edsico restrito, que s\u00e3o leg\u00edveis por m\u00e1quina - documentos XML - representam uma inova\u00e7\u00e3o, ao mesmo tempo que s\u00e3o uma analogia familiar e confort\u00e1vel do documento. O que n\u00e3o impede que continuem sendo uma maneira errada e excessivamente skeuom\u00f3rfica de representar dados.<\/p>\n
At\u00e9 agora, as \u00fanicas esquemas XML que realmente considero uma aplica\u00e7\u00e3o correta deste formato s\u00e3o XHTML e DocBook.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042f\u0437\u044b\u043a XML \u0431\u044b\u043b \u0438\u0437\u043e\u0431\u0440\u0435\u0442\u0435\u043d \u0432 1996 \u0433\u043e\u0434\u0443. \u0415\u0434\u0432\u0430 \u043e\u043d \u0443\u0441\u043f\u0435\u043b \u043f\u043e\u044f\u0432\u0438\u0442\u044c\u0441\u044f, \u043a\u0430\u043a \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0435\u0433\u043e \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0443\u0436\u0435 \u043d\u0430\u0447\u0430\u043b\u0438 \u043f\u043e\u043d\u0438\u043c\u0430\u0442\u044c \u043d\u0435\u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e, \u0438 \u0434\u043b\u044f \u0442\u0435\u0445 \u0446\u0435\u043b\u0435\u0439, \u043a \u043a\u043e\u0442\u043e\u0440\u044b\u043c \u0435\u0433\u043e \u043f\u044b\u0442\u0430\u043b\u0438\u0441\u044c \u0430\u0434\u0430\u043f\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c, \u043e\u043d \u0431\u044b\u043b \u043d\u0435 \u043b\u0443\u0447\u0448\u0438\u043c \u0432\u044b\u0431\u043e\u0440\u043e\u043c. \u041d\u0435 \u0431\u0443\u0434\u0435\u0442 \u043f\u0440\u0435\u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u0435\u043c \u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u0447\u0442\u043e \u043f\u043e\u0434\u0430\u0432\u043b\u044f\u044e\u0449\u0435\u0435 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u0441\u0445\u0435\u043c XML, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043d\u0435 \u0434\u043e\u0432\u043e\u0434\u0438\u043b\u043e\u0441\u044c \u0432\u0438\u0434\u0435\u0442\u044c, \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u043b\u0438 \u0441\u043e\u0431\u043e\u0439 \u043d\u0435\u0446\u0435\u043b\u0435\u0441\u043e\u043e\u0431\u0440\u0430\u0437\u043d\u043e\u0435 \u0438\u043b\u0438 \u043d\u0435\u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 XML. \u0411\u043e\u043b\u0435\u0435 \u0442\u043e\u0433\u043e, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":52641,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52640","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"O](\"\/wp-content\/uploads\/2019\/11\/8152077415a94ef74806af230ef44bd7.jpg\")