Os esquemas XML são ruins para formatos de arquivo em constante evolução?

5

Estou lutando com um projeto cliente-servidor no qual tenho aplicativos Java na Internet que armazenam dados em um servidor de back-end. O formato desses dados é bem definido, mas o projeto está em constante evolução, então a definição continua mudando! Para lidar com a mudança, defini uma interface REST simples no servidor que oferece apenas armazenamento de valor-chave. Os clientes podem armazenar ou recuperar um bloco de dados referenciando uma chave exclusiva. Isso é bom porque eu não tenho que modificar a interface do servidor (ou o banco de dados de back-end) quando o formato de dados é alterado. Para o servidor, é apenas um monte de blobs opacos.

Claro, a questão então se torna "O que há dentro da bolha?" Para isso eu escrevi um XML Schema que define o conteúdo de um blob. No começo foi ótimo, uma vez que o Schema fornece um monte de coisas legais "de graça": uma especificação formal do formato de arquivo, validação automática de seu conteúdo, empacotamento / desmarcação para um fluxo, e Java gerado automaticamente classes para acesso programático aos dados.

Mas então aconteceu a mudança! O esquema teve que ser alterado e, naturalmente, me deparei com problemas de compatibilidade com versões anteriores e posteriores. Para lidar com o esquema em constante mudança, criei uma solução que incorpora um número de versão no namespace XML e aplico uma série de folhas de estilo XSL para "atualizar" qualquer blob fornecido para a versão mais recente. Por exemplo, estou agora na versão 1.3 do meu Schema, então quando eu desempago um blob, eu o executo através de um XSLT de 1.0 para 1.1, então um XSLT de 1.1 para 1.2, e finalmente um 1.2 para 1.3 XSLT. Isso funciona, mas não é sustentável porque a cadeia continua ficando mais longa, o que reduz o desempenho e suga a memória, além de eu ter que escrever novos Stylesheets, o que leva tempo e não é divertido.

Agora aqui está a coisa engraçada ... Além dos clientes Java, o projeto também tem aplicativos iOS como clientes, e o iOS não tem nenhum dos recursos corporativos agradáveis associados aos XML Schemas. Não há validação do fluxo, nenhuma geração automática de classes Objective-C, etc., apenas um analisador XML orientado a eventos de baixo nível. Mas, ironicamente, estou achando isso tão muito mais fácil! Por exemplo, se o XML obtiver um novo elemento, adicionarei uma nova cláusula if . Se um elemento desaparecer, eu removo sua cláusula. Basicamente, eu faço um "melhor esforço" para interpretar o fluxo XML, ignorando silenciosamente quaisquer elementos não reconhecidos. Não preciso pensar em qual versão o formato de arquivo é ou se é válido. Além disso, isso é muito mais rápido porque não há encadeamento XSLT e economiza muito do meu tempo, porque não preciso escrever nenhum código XSLT.

Até agora, essa abordagem funcionou muito bem, e eu não senti falta de ter um esquema XML no lado do iOS. Agora estou me perguntando se um esquema, apesar de seu bom conjunto de recursos, é totalmente a tecnologia errada para um formato de arquivo que muitas vezes muda. Estou pensando em abandonar meu XML Schema completamente e usar a mesma abordagem de baixo nível "melhor esforço" em Java que estou fazendo no iOS.

Então minha avaliação negativa de XML Schemas está correta? Ou há algo que eu perdi? Talvez eu precise repensar a interface do servidor? Ou talvez eu não deveria ter usado XML em primeiro lugar? Estou aberto a todas as sugestões. Obrigado pela leitura!

    
por vocaro 11.02.2012 / 02:47
fonte

1 resposta

8

Acho que você está realmente fazendo uma pergunta mais ampla, "é ter uma definição rígida de um formato de arquivo bom para um projeto em rápida evolução".

Para responder à sua pergunta imediata, porém: sim, eles são. O esquema XML fornece uma definição estrita do formato, responde a muitas perguntas sobre validade, fornece excelente documentação e permite que você saiba com confiança que uma versão específica do documento tem um formulário específico.

Eles não são o todo e o fim de tudo: eles definem estrutura, não semântica, então você ainda pode mudar o "significado" de uma tag entre a versão do documento sem ter que alterar o esquema. Isso causa muitos problemas.

Para responder à pergunta, acho que você está perguntando: sim, o esquema XML é uma coisa boa.

Ele está forçando você a lidar com um fato doloroso, que é que sua troca de dados está constantemente mudando de versão, e isso significa que você precisa adaptar seu sistema para dar conta disso.

Se você tivesse apenas o modelo IOS, em que você entende "o que essa versão significa", você abre a porta para todo tipo de problema a longo prazo. Por exemplo, torna-se trivial para alguém assumir que "elemento foo estar presente significa a versão 1.2, então tag bar significa ...".

Isso é ótimo, até a versão 2.0 adicionar de volta o elemento foo, com um significado diferente, e a barra de tags nem está lá. Bem-vindo à cidade "comportamento inconsistente".

Se você usa XML sem esquemas, ou JSON, ou qualquer outra coisa que não imponha esse custo a você, apenas um pouquinho do problema desaparece. Você ainda tem que lidar com todas as quatro versões da entrada, mas você tem menos ferramentas para ajudá-lo.

Você deve, na minha opinião, preferir geralmente tornar a dor das mudanças proporcional ao seu custo real e de longo prazo. Mudar o formato de troca de dados tem um alto custo a longo prazo - você tem que lidar com compatibilidade, com atualizações de dados e esse tipo de coisa.

Se isso custa pouco, você será tentado a fazer muito, e então pagará o custo de manutenção amanhã. Se custar mais agora, você pode pensar mais - você pode fazer mais do que uma coisa nessa mudança? Você pode fugir sem ele? Você consegue fazer isso de maneira mais inteligente?

Em suma, acho que o seu problema real é que o formato do arquivo é alterado com frequência, e não que você usou (ou não usou) esquemas XML.

(Além disso, os seus usuários estão realmente felizes se o servidor ou o cliente deixar aleatoriamente o conteúdo representado na versão mais recente? Eu ficaria surpreso se isso permanecer verdadeiro para sempre - outro desses custos de longo prazo que você precisa reconhecer em algum lugar. .)

    
por 11.02.2012 / 02:55
fonte