Estratégia de versão do esquema xml

Estratégia de versão do esquema Xml
Muitas vezes tenho que projetar esquemas XML para diferentes rotinas de importação de bases XML. É claro que os esquemas XML evoluirão com o tempo ou poderão conter bugs a serem corrigidos, portanto, é importante capturar a versão do esquema e ter algum mecanismo para vincular-se a uma versão específica.
Atualmente tenho dois cenários:
O bug é encontrado dentro do esquema e todas as instâncias do esquema devem estar em conformidade com a versão corrigida.
O esquema foi atualizado e deve ser considerado como preferível, mas um antigo deve ser também suportado.
Finalmente eu inventei armazenar informações sobre a versão dentro do namespace do esquema:
Ao consertar um bug, corrijo-o no mesmo namespace, mas se estou prestes a atualizar um esquema, preciso criar um novo namespace, mas com o mês de upgrade adicionado:
E se eu tiver mais de um upgrade em um mês, acrescente apenas um dia também:
Você conhece alguma abordagem melhor?
Este é um assunto tão difícil que nem é engraçado, e que eu passei anos fornecendo suporte de consultoria para.
Existem muitas práticas recomendadas por aí, mas a maioria delas não funciona em todas as situações. Por exemplo, muitos defendem o uso de "xsd: any" para permitir extensões, e isso é apenas uma receita para o desastre se os desenvolvedores estiverem encarregados de manter o esquema, transformando-o em um dump.
Aqui estão algumas dicas para você se estiver começando:
Não coloque um número de versão secundária, número de versão micro, data ou qualquer outra coisa do tipo em seu namespace. Toda vez que você alterar o namespace, você quebrará todos os aplicativos de processamento. Coloque um atributo "version" no documento da instância XML. Isso permitirá que um aplicativo de processamento ou um serviço de adaptador de versão descubra o que está processando. Especifique uma política do que constitui uma mudança compatível com versões anteriores, por exemplo: adicionar elementos opcionais não interromperá os remetentes e não interromperá os receptores se usarem uma política de ignorar elementos que não conhecem (o JAXB e o XMLBeans podem ser configurados dessa maneira )

BizTalk Fringe.
Contos da fronteira de integração:
"Como é que quando ninguém sabe e não faz sentido, eles vêm até nós?"
domenica, gennaio 09, 2011.
Estratégia de versionamento do BizTalk (2/4)
Esta é a segunda parte da discussão sobre versionamento, a primeira parte aqui.
Mensagens e Objetos: Dois lados da mesma moeda.
O BizTalk tem um dualismo estranho quando se trata de processamento de mensagens:
De um lado, o BizTalk é um aplicativo e, portanto, uma mensagem é identificada por seu Tipo, a montagem que o contém e seu Nome Forte.
Por outro lado, o BizTalk é um middleware de processamento Orientado a XML e, portanto, uma mensagem (se for um xml) também é identificada por suas características XSD (o que é chamado na terminologia do BizTalk de seu tipo de mensagem). identificado pelo nome do nó raiz e pelo namespace)
No exemplo abaixo, cliquei duas vezes em um esquema implementado no console de administração do biztalk, apenas para descobrir que o esquema é identificado pelo seguinte par de propriedades:
Tipo: BizTalk_Server_Project1.Schema1, BizTalk Server Projeto1, versão = 1.0.0.0, Culture = neutral, PublicKeyToken = a76ffbe6c9882f67.
O mesmo dualismo pode ser lido em uma instância de mensagem inspecionada por meio do console de administração: como você pode observar nas propriedades de contexto MessageType e SchemaStrongName.
Por que essa distinção é importante?
Essa distinção é extremamente importante porque nos ajuda a entender alguns comportamentos biztalk estranhos e antecipar problemas de versionamento:
Se você tentar implantar dois esquemas diferentes, mas com o mesmo nome de nó raiz e espaço de nomes em dois assemblies diferentes, o BizTalk explodirá assim que uma mensagem correspondente ao esquema entrar na caixa de mensagem com a seguinte exceção.
Não é possível localizar a especificação do documento porque vários esquemas corresponderam ao.
tipo de mensagem "http: / MySchema1 # Root"
(O mais desagradável desse problema é que obviamente afeta todas as mensagens que correspondem ao esquema, não apenas as mensagens da implantação incorreta, isso significa que um dia um processo funciona corretamente, um dia depois de alguém decidir implantar outro esquema para outro projeto sem perceber a incompatibilidade de tipo de mensagem e o processo que estava funcionando corretamente não está mais funcionando. Esta experiência me ensinou a colocar esquemas em assemblies separados para sistemas em vez de processos: reduzir a possibilidade de colocar o mesmo tipo de mensagem em assembly diferente porque geralmente o nome do sistema é também contido no namespace xml da mensagem)
Conhecendo o dualismo descrito acima, o problema agora está claro:
BizTalk receber uma mensagem XML do externo, a primeira coisa que faz é procurar em seu banco de dados para encontrar o tipo relacionado a essa mensagem XML (usando MessageType como chave).
Se tiver duas correspondências, não poderá decidir qual tipo usar para desserialização de mensagens e lançará a exceção.
Mas, se você implantar o mesmo tipo de mensagem em outra versão do mesmo assembly, nenhuma exceção será gerada.
Isso se deve ao fato de que (como descrito aqui) o mecanismo biztalk tem uma exceção à regra sem vários resultados: Se a correspondência múltipla vier de versões diferentes do mesmo assembly, o esquema vindo do mais recente (versão mais alta) será usado.
Equipado com todos esses novos conhecimentos, vamos ver como cada artefato biztalk irá reagir a uma atualização de esquema (isto é, versão de esquema antiga = 1.0.0.0 enquanto o novo esquema é implementado lado a lado com a versão = 1.0.0.1).
O componente XmlDisassembler é responsável por identificar e promover o MessageType e o SchemaStrongName da mensagem.
Portanto, aplicando o que é visto até agora, o xmldisassembler atribuirá o MessageType sem problemas (afinal, ele simplesmente concatena o nome Root e o namespace) e resolverá o SchemaStrongName para a versão 1.0.0.1.
Se, por alguma razão, você quiser sobrescrever o & # 8220; padrão para versão superior & # 8221; regra você pode indicar explicitamente o SchemaStrongName nos "Esquemas do documento" & # 8221; propriedade do componente de pipeline.
Mapas são simplesmente transformações XLST, portanto, eles geralmente não são de todo interessados ​​em SchemaStrongNames ou Types, mas olham apenas para o MessageType.
Na verdade, ao colocar vários mapas em uma porta, uma mensagem é direcionada para um ou outro mapa apenas examinando seu tipo de mensagem e nada mais.
Mas, em tempo de compilação, os mapas são compilados contra esquemas biztalk (esquemas de origem e de destino) e, portanto, no final dos mapas de transformação, simplesmente & # 8220; anexar & # 8221; o destino esperado MessageType e SchemaStrongName para a mensagem de saída.
Em outras palavras, se você tiver compilado seu mapa com a versão 1.0.0.0 de seu esquema, o mapa continuará funcionando sem problemas se você enviar uma versão 1.0.0.1 de sua mensagem para dentro, mas produzirá uma versão 1.0.0.0 do resultado.
As orquestrações são diferentes: elas são um bloco de código estaticamente compilado e, portanto, não estão cientes das mensagens XML, mas só entendem os tipos.
Portanto, se você enviar para uma orquestração (compilada na versão 1.0.0.0) mensagens com a versão 1.0.0.1, mesmo que elas sejam idênticas (de um ponto de vista de xml) a uma orquestração de mensagem 1.0.0.0, haverá uma exceção ( & # 8220; Recebido tipo de mensagem inesperada & # 8221; visto na parte anterior).
Fazendo uma rápida recapitulação, portanto, podemos dizer que a implantação do esquema lado a lado com o seu & ldquo; padrão para a versão superior & # 8221; regra é boa quando você apenas mapeia e faz pipelines (então é perfeito em um cenário somente de mensagens), mas falhará miseravelmente se você orquestrar em sua solução.
Na próxima parte, tentaremos encontrar uma solução para esse problema.

[Editorial Draft] Estendendo e Versando Idiomas: XML Languages.
Rascunho do TAG em 04 de julho de 2007.
Este documento discute os aspectos relacionados ao XML dos versionamentos. Ele descreve a terminologia baseada em XML, tecnologias e estratégias de versão. Ele fornece exemplos de esquemas XML para cada uma das estratégias e discussões sobre vários padrões de design de esquema. Várias linguagens XML, incluindo XHTML e Atom, são usadas como estudos de caso em diferentes estratégias.
Status deste documento.
Este documento foi desenvolvido para discussão pelo Grupo de Arquitetura Técnica do W3C. Ainda não representa a opinião consensual do TAG.
A publicação desta descoberta não implica o endosso da filiação ao W3C. Este é um documento preliminar e pode ser atualizado, substituído ou tornado obsoleto por outros documentos a qualquer momento.
Achados adicionais do TAG, aprovados e em estado de rascunho, também podem estar disponíveis. A TAG espera incorporar essa e outras descobertas em um documento de arquitetura da Web que será publicado de acordo com o processo da faixa de recomendações do W3C.
Por favor, envie comentários sobre esta descoberta para a lista de discussão TAG publicamente arquivada www-tag @ w3 (arquivo).
Índice.
1. Introdução.
Estendendo e Versionando Linguagens XML A Parte 1 descreveu as linguagens de extensão e versão. A Parte 2 se concentra em XML e inclui aspectos específicos da linguagem de esquema de XML de extensão e de versão. As escolhas, decisões e estratégias descritas na Parte 1 são aumentadas com as instâncias XML e XML Schema.
1.1 Terminologia XML.
Descreveremos alguns refinamentos importantes em nossa terminologia de versão para XML. Uma linguagem XML tem um vocabulário que pode usar termos de um ou mais Namespaces XML (ou nenhum), cada um deles com um nome de namespace. [Definição: Uma linguagem XML é onde todos os Textos DEVEM ser XML bem formado]. Como XML é uma linguagem de marcação, as partes mais significativas de XML Languages ​​são os elementos e atributos. [Definição: Um componente é um elemento ou atributo XML]. A Linguagem do Nome - consistindo de nome, dados, termos familiares - tem um namespace para os termos. Usamos o prefixo "namens" para nos referirmos a esse namespace. A linguagem de nomes pode consistir em termos de outros vocabulários, como o Dublin Core ou o UBL. Cada um desses termos tem seus próprios namespaces, ilustrando que um idioma pode ser composto de termos de vários namespaces. Um Namespace XML é um contêiner conveniente para coletar termos que devem ser usados ​​juntos em um idioma ou em idiomas. Ele fornece um mecanismo para criar nomes globalmente exclusivos.
Usamos o termo instância quando falamos de sequências de caracteres (também texto) em XML. [Definição: Uma instância é um Texto de XML bem formado e os textos são geralmente restritos por uma linguagem de esquema.] A linguagem de esquema pode ser processável por máquina como DTDs, XML Schema, Relax NG ou a linguagem de esquema pode ser legível por humanos texto. Documentos são instâncias de um idioma. Em XML, eles devem ter um elemento raiz. Um texto de nome pode ter um elemento de nome como o elemento raiz. Como alternativa, o vocabulário de nomes pode ser usado por outro idioma, como pedidos de compra, para que os textos do pedido de compra possam conter textos que possam ser considerados textos de nome. Assim, instâncias de uma linguagem XML são sempre pelo menos parte de um texto e podem ser o texto inteiro. Instâncias XML (e todas as outras instâncias de linguagens de marcação) consistem em marcação e conteúdo. No exemplo do nome, os elementos given e family, incluindo os marcadores finais, são a marcação. Os valores entre os marcadores de início e fim são o conteúdo. Uma instância possui um modelo de informações. Há uma variedade de modelos de dados dentro e fora do W3C, e o padronizado pelo W3C é o infoset XML.
Os termos relacionados ao XML e seus relacionamentos são mostrados abaixo.
ednote: Atualização para a versão final da terminologia.
Alguns exemplos de consumidores e produtores XML são: Um processador de folhas de estilo é um consumidor do texto XML que está processando (o produtor não é mencionado); no contexto de serviços da Web, as funções de produtor e consumidor se alternam conforme as mensagens são passadas de um lado para outro. Observe que a maioria das especificações de serviços da Web fornece definições de entradas e saídas. Por nossas definições, um serviço da Web que atualiza seu esquema de saída é considerado um novo produtor. Um serviço da Web que atualiza seu esquema de entrada é um novo consumidor.
1.2 Tipos de Idiomas XML.
Por fim, existem diferentes tipos de linguagens XML. As abordagens de versionamento e estratégias apropriadas para um tipo de linguagem podem não ser apropriadas para outro. Entre os vários tipos de vocabulários, encontramos:
Apenas Nomes: algumas linguagens não identificam elementos ou atributos; São apenas listas de nomes. Usando QNames para identificar palavras no banco de dados WordNet, por exemplo, ou os nomes de funções e operadores no XPath2 são exemplos de idiomas "apenas de nome".
Independente: idiomas projetados para serem usados ​​mais ou menos sozinhos, por exemplo, XHTML, DocBook ou The TEI.
Containers: linguagens projetadas para serem usadas como um wrapper ou framework para alguma outra linguagem ou payload, por exemplo, SOAP ou WSDL.
Extensões de Contêiner: linguagens projetadas para ampliar ou aumentar uma classe específica de contêiner. As especificações que estendem o SOAP definindo blocos de cabeçalho SOAP, por exemplo, para fornecer segurança, assincronização ou mensagens confiáveis, são exemplos de linguagens de extensão de contêiner.
Existem alguns tipos de linguagens de extensão XML, extensão de elemento e tipo ou extensão de atributo.
Extensão de Elemento. Idiomas que são elementos. SOAP, etc. são extensões de elementos.
Atributo ou Tipos. Idiomas que definem tipos ou atributos. Essas linguagens devem existir no contexto de um elemento que não é definido pela linguagem. Às vezes chamado de "parasita" línguas como eles exigem um elemento "host". XLink é um exemplo.
Misturas: linguagens projetadas para, ou frequentemente usadas para, encapsular algumas semânticas dentro de outra linguagem. Por exemplo, o MathML pode ser misturado dentro de outro idioma.
Esta não é de maneira alguma uma lista exaustiva. Essas categorias também não são completamente claras. MathML certamente pode ser usado de forma independente, por exemplo, e linguagens como SVG são uma combinação de contêineres e misturas.
2 Requisitos de Linguagem XML.
As questões de linguagem geral descritas na Parte 1 Requisitos (../versioning#requirements). Esses requisitos são aumentados em XML por:
Precisão do esquema XML para as versões da linguagem. Por exatidão, queremos dizer o grau em que a linguagem é descrita. Veremos como alguns projetos impedem a descrição completa do esquema XML. Geralmente, isso resulta em esquemas incompletos na primeira e nas versões subsequentes. As opções são normalmente: Completas em todas as versões, completas apenas na primeira versão, incompletas em todas as versões.
Uso de ferramentas genéricas XML e somente namespace (impedindo versões específicas de vocabulário). Isso por si só é uma desvantagem porque algumas ferramentas XML genéricas (como XPath) são mais difíceis de usar com múltiplos namespaces contendo a mesma "coisa", como o elemento P de XHTML.
3 tecnologias de identificação de versão.
A identificação de versão de elementos e atributos geralmente é uma parte importante do processamento correto de documentos xml. Há uma grande variedade de tecnologias de identificação de versão em XML. As tecnologias fundamentais disponíveis para identificação de versões em um documento XML são:
Nomes Qualificados: Namespaces + Nome Local.
As decisões sobre quais tecnologias usar são afetadas pelos requisitos gerais de idioma e pelos ambientes XML.
3.1 Nome Qualificado: Espaço de Nomes + Nome Local.
Muitos sistemas usam informações de tipo associadas ao componente como parte da identificação de versão do componente. Geralmente, existem duas estratégias para determinar o tipo de componente, que chamaremos de "Digitação superior" e "Digitação inferior". Top-typing é um estilo onde o tipo do componente é determinado pelo tipo do elemento top. A digitação de baixo é um estilo em que o tipo do componente é determinado pelo tipo ou tipos de descendentes do elemento superior. Os projetos de digitação de fundo podem ser de tal forma que um único tipo não seja possível, em vez disso, é efetivamente o composto de todos os tipos descendentes. Quando os tipos principais são estendidos, o tipo fica mais difícil de especificar. Poderia ser o tipo de topo, ou poderia ser o tipo de topo mais todos os tipos de extensão. Um nameType estendido com um middleNameType pode ser considerado um nameType ou um nameType + middleNameType. À medida que o número de tipos de extensão aumenta, a especificação do tipo real pode se tornar equivalente a alguns designs de digitação de fundo. O extremo disso são as linguagens de contêiner, que têm um único tipo superior invariável e geralmente destinam-se a ter o tipo determinado pelo conteúdo na "parte inferior" do contêiner.
Em ambos os casos, o (s) tipo (s) usado (s) para determinação de tipo é determinado pelo tipo associado ao nome qualificado do componente durante a atribuição de tipo. No esquema XML, isso ocorre durante a validação. Também é possível especificar o tipo na instância. O esquema XML fornece um atributo xsi: type que especifica o tipo do componente. Isso substitui a associação entre o nome qualificado do componente e o tipo, conforme especificado no esquema, ou fornece um tipo em que o nome qualificado do componente pode não ser resolvido em um tipo.
O XML Schema é projetado para atribuir informações de tipo como parte da validação. Outras linguagens, notavelmente RelaxNG, não atribuem informações de tipo e não têm noção de tipos. A decisão de usar tipos e reutilizar tipos entre os componentes é um fator importante na identificação da versão do componente, pois a definição do componente e o tipo do componente podem ser versionados separadamente.
3.3 Números de Versões.
Uma desvantagem significativa ao usar identificadores de versão em XML é que o software que suporta as duas versões do nome deve executar um processamento especial em cima de XML e namespaces. Por exemplo, muitos componentes “ligam” tipos XML em tipos de linguagem de programação específicos. O software personalizado deve processar o atributo de versão antes de usar qualquer um dos softwares de “ligação”. Nos serviços da Web, os kits de ferramentas geralmente obtêm conteúdo do corpo SOAP, analisam-no em tipos e invocam métodos nos tipos. Raramente há “ganchos” para o código personalizado interceptar o processamento entre o processamento de “SOAP” e o processamento de “nome”. Além disso, se os atributos de versão forem usados ​​por qualquer extensão de terceiros, por exemplo, midns: o middle tem uma versão, o esquema não poderá se referir ao tipo do meio correto.
4 Estratégias de identificação de versão de componentes.
A estratégia para identificar a versão de um componente talvez seja a decisão mais importante no design de uma linguagem XML. O uso de nomes de espaço de nomes, nomes de componentes, números de versão e informações de tipo são essenciais para obter as características de versão desejadas. As estratégias variam de muitos namespaces por versão de um idioma a apenas um namespace para todas as versões de um idioma. Alguns dos mais comuns estão listados abaixo e descritos em mais detalhes posteriormente.
ou seja, a primeira versão consiste em namespaces a + b, a próxima versão compatível ou incompatível consiste em namespaces c + d; ou a primeira versão consiste em namespace a, a próxima versão compatível ou incompatível consiste em namespace b.
ou seja, primeira versão consiste em namespace a; a próxima versão compatível consiste em namespaces a + b; A próxima versão incompatível consiste em namespaces c + d.
ou seja, a primeira versão consiste em namespace a, a próxima versão compatível consiste em namespace a + b com adições ao namespace a.
ou seja, a primeira versão consiste em um namespace a, a próxima versão compatível consiste em namespace a, a próxima versão incompatível consiste em namespace b.
ou seja, a primeira versão consiste em um atributo de namespace a + b + version “1”, a próxima versão compatível ou incompatível consiste no namespace c + d + version attribute “2”.
ou seja, primeira versão consiste em namespace um atributo + versão “1.0”, a próxima versão compatível consiste em namespace a + atributo de versão “1.1”, a próxima versão incompatível consiste em namespace a + atributo de versão “2.0”.
Seja qual for o design escolhido, o designer de idiomas deve decidir o nome do componente, o nome do namespace e qualquer identificador de versão para componentes novos e todos os existentes.
Elaborar esses projetos é ilustrativo.
4.1 Estratégia de Versão # 1: todos os componentes em novos namespace (s) para cada versão.
Os nomes a seguir seriam válidos:
O 2 o e 3 o exemplos mostram todos os componentes no mesmo novo espaço de nomes, com o 3º também mostrando um novo nome. O 4º e o 5º exemplo mostram um elemento intermediário adicional em 2 nomes diferentes de namespace. O quarto exemplo vem de um nome de namespace que está no mesmo domínio que o nome do novo namespace do elemento name. Um motivo para dois namespaces é modularizar o idioma. O 5º exemplo mostra um nome de namespace de um domínio diferente para o meio.
4.1.1 Vantagens e Desvantagens
Nessa estratégia, a compatibilidade com versões futuras não é desejada. Qualquer alteração ou extensão é uma alteração incompatível com um consumidor existente. Quando um consumidor mais velho recebe os novos textos no novo namespace, a maioria do software será quebrada, como a execução de uma validação de esquema sem o novo esquema. A obtenção de compatibilidade com versões futuras de partes de um sistema é possível e requer uma seleção cuidadosa de tecnologias, como expressões XPath que são agnósticas para namespaces. O efeito da mudança ser uma mudança incompatível para a frente é o objetivo do projeto de alguns sistemas que adotaram essa estratégia.
4.2 Estratégia de versionamento # 2: todos os novos componentes em novos namespace (s) para cada versão compatível.
Nesta estratégia, os seguintes nomes seriam válidos:
O segundo e terceiro exemplos mostram um elemento intermediário adicional em dois nomes de namespace diferentes. O primeiro meio, o segundo exemplo, vem de um nome de namespace que está no mesmo domínio que o nome do namespace do elemento name. O terceiro exemplo mostra um nome completo de namespace para o meio. É provável que o midns: middle foi criado pelo autor do nome e o middiffdomain: middle foi criado por um terceiro.
4.2.1 Vantagens e Desvantagens.
A compatibilidade para trás e para frente pode ser suportada a partir da primeira versão. Esse design impede que o designer de linguagem reutilize um nome de namespace para alterações, o que pode ser desejável, já que a introdução de novos nomes de espaços de nomes pode ser difícil. O XML Schema geralmente não suporta mais de uma revisão compatível do esquema nesta estratégia, como mostrado em 7.2 # 2: todos os novos componentes em novos namespace (s) para cada versão compatível.
4.3 Estratégia de Versionamento # 2.5: todos os novos componentes no (s) namespace (s) novo (s) ou existente (s) para cada versão compatível.
Nós chamamos essa estratégia de "2.5" porque é uma mistura de estratégia # 2 e estratégia # 3. Nesta estratégia, os seguintes nomes seriam válidos:
O segundo exemplo mostra o uso do nome do meio opcional no nome namespace. O terceiro e o quarto exemplo mostram um elemento intermediário adicional em dois nomes diferentes de namespace. O primeiro meio, o terceiro exemplo, vem de um nome de namespace que está no mesmo domínio que o nome do namespace do elemento name. O 4º exemplo mostra um nome de espaço para nome completamente diferente para o meio. É provável que o midns: middle foi criado pelo autor do nome e o middiffdomain: middle foi criado por um terceiro.
4.3.1 Vantagens e Desvantagens.
A compatibilidade para trás e para frente pode ser suportada a partir da primeira versão. Dependendo do design do esquema, alguns novos componentes não exigem uma alteração de namespace. O XML Schema geralmente não suporta mais de uma revisão do esquema de maneira compatível nos novos componentes em novos namespace (s) para cada estratégia de versão compatível, como mostrado em 7.2 # 2: todos os novos componentes em novos namespace (s) para cada versão compatível.
4.4 Estratégia de Versão # 3: todos os novos componentes no (s) espaço (s) de nomes existente (s) para cada versão compatível.
Nesta estratégia, os seguintes nomes seriam válidos:
O segundo exemplo mostra o uso do mesmo namespace, porque o meio é opcional. O terceiro exemplo mostra o uso do mesmo espaço de nomes porque o meio é opcional e o meio é incorporado dentro de um "elemento de extensão". O 4º exemplo mostra o uso de um novo namespace para todos os componentes, como um nome do meio obrigatório.
4.4.1 Vantagens e Desvantagens.
A compatibilidade para trás e para frente pode ser suportada a partir da primeira versão sem alterações no namespace. Isso significa que novos componentes não exigem novos namespaces, o que geralmente significa menos chances de evolução incompatível. O uso de namespace existente ou novo dá ao designer de linguagem maior escolha no uso de nomes de namespace do que apenas usando um novo namespace. Como sempre, somente o designer de idiomas tem a capacidade de usar e aumentar o nome do namespace da primeira versão. O XML Schema não oferece suporte ao segundo exemplo em muitas situações, devido à restrição Unique Attrand Attribution. O XML Schema suporta o terceiro exemplo, como mostrado em 7.4 # 3: Todos os novos componentes no (s) namespace (s) existente (s) para cada versão compatível.
4.5 Estratégia de versionamento # 4: todos os novos componentes em namespace existente ou novo (s) para cada versão e um identificador de versão.
Usando um identificador de versão, as instâncias de nome seriam alteradas para mostrar a versão do nome que elas usam, como:
Nos dois últimos exemplos, o número da versão foi alterado de 1.0 para 2.0. Incrementar a maior parte de um número de versão geralmente indica uma alteração incompatível. Nesse caso, talvez isso indique que o nome do meio agora é obrigatório, onde antes era opcional.
4.5.1 Vantagens e Desvantagens.
A compatibilidade para trás e para frente pode ser suportada a partir da primeira versão sem alterações no namespace. No entanto, o uso de números de versão significa que o relacionamento ou ligação entre o Nome Qualificado de um componente e a interpretação de um idioma requer o uso do número da versão. Isso significa que ferramentas de vinculação geral, como XML para mapeamentos Java, geralmente não podem ser usadas autônomas.
4.6 Estratégia de versionamento # 5: todos os componentes no (s) espaço (s) de nomes existente (s) para cada versão e um identificador de versão.
Usando um identificador de versão, as instâncias de nome seriam alteradas para mostrar a versão do nome que elas usam, como:
O segundo exemplo mostra que o meio é uma parte opcional do nome. O último exemplo mostra que o meio é uma parte obrigatória do nome.
4.6.1 Vantagens e Desvantagens.
A compatibilidade para trás e para frente pode ser suportada a partir da primeira versão sem alterações no namespace. O software que extrai o nome e o sobrenome fornecidos com base no nome Qualificado geralmente não será interrompido porque um novo nome de namespace não é usado. No entanto, o uso de números de versão significa que o relacionamento ou ligação entre o Nome Qualificado de um componente e a interpretação de um idioma requer o uso do número da versão. Isso significa que ferramentas de vinculação geral, como XML para mapeamentos Java, não podem ser usadas autônomas.
5 Indicando compatibilidade de alterações ou extensões.
Como um designer de linguagem terá escolhido uma estratégia de identificação de versão de componente, ele também deve escolher como as alterações compatíveis ou incompatíveis serão indicadas.
5.1 Compatível
Conforme mencionado na seção de compatibilidade de encaminhamentos, a compatibilidade de encaminhamento requer um mecanismo de substituição. Ignorando conteúdo desconhecido é um modelo muito popular. Pode ser especificado como padrão para qualquer extensão. Também pode ser especificado em uma instância em que o padrão é o controle de versão incompatível. Isso pode ser um sinalizador, como ns: mayIgnore = "true".
5.2 Incompatível.
Um autor de versão pode usar novos nomes de namespace, nomes locais ou números de versão para indicar uma alteração incompatível. Um autor de extensão pode não ter esses mecanismos disponíveis para indicar uma extensão incompatível. Um projetista de idiomas que deseja permitir que os autores de extensão indiquem que uma extensão é incompatível deve fornecer um mecanismo para indicar que os consumidores devem entender a extensão, e o consumidor deve gerar um erro se não entender a extensão. Se apenas consumidores específicos precisarem entender a extensão, o designer de idiomas também deve fornecer um mecanismo para indicar quais consumidores. Se o designer de idiomas tiver permitido a compatibilidade para frente, a regra de compatibilidade de encaminhamento deverá ser cancelada.
Idiomas com suporte à compatibilidade com versões futuras PODEM fornecer uma substituição para indicar extensões incompatíveis, mas devem fazê-lo SE as extensões incompatíveis puderem ser claramente segmentadas ou com escopo definido.
5.2.1 Deve entender a bandeira.
Indiscutivelmente o mais simples e mais flexível over-ride da técnica Must Ignore Unknowns é um Must Understand que indica se o item deve ser entendido. Os atributos e valores SOAP, WSDL e WS-Policy para especificar o entendimento são respectivamente: soap: mustUnderstand = ”1”, wsdl: required = ”1”, wsp: Uso = ”wsp: Required”. O SOAP é provavelmente o caso mais comum de um contêiner que fornece um modelo Must Understand. O valor padrão é 0, que é efetivamente a regra Must Ignore.
Um projetista de linguagem pode reutilizar um modelo Must Understand existente restringindo sua linguagem a um modelo Must Understand existente. Diversas especificações de serviços da Web fizeram isso especificando que os componentes são blocos de cabeçalho SOAP, que trazem explicitamente o modelo SOAP Must Understand.
Um designer de linguagem pode projetar um modelo Must Understand em seu idioma. Um sinalizador Must Understand permite que o produtor insira extensões no contêiner e use o atributo Must Understand para sobrepor a regra de ignorar obrigatória. Isso permite que os produtores estendam as instâncias sem alterar o espaço para nome do pai do elemento de extensão, mantendo a compatibilidade com versões anteriores. Obviamente, o consumidor deve ser ampliado para lidar com novas extensões, mas agora há um acoplamento flexível entre o modelo de processamento do idioma e o modelo de processamento da extensão. Um sinalizador Deve entender é fornecido abaixo:
Um exemplo de uma instância de um terceiro que indica que um componente do meio é uma alteração incompatível:
A especificação de um sinalizador Deve Entender deve ser tratada com cuidado, pois pode ser computacionalmente cara. Normalmente, um processador irá: executar uma varredura para componentes Must Understand para garantir que possa processar todo o texto ou processar a instância incrementalmente e está preparado para reverter ou desfazer qualquer processamento se um Must Understand não entendido for encontrado.
Existem outros refinamentos relacionados ao Must Understand. Um exemplo é fornecer um elemento que indica quais namespaces de extensão devem ser compreendidos, o que evita a varredura da instância para os sinalizadores Must Understand.
Também é possível reutilizar o modelo de processamento SOAP com mustUnderstand. O uso de um cabeçalho SOAP para uma extensão pode ser porque o corpo não foi projetado para ser extensível ou porque a extensão é considerada semanticamente separada do corpo e normalmente será processada de maneira diferente do corpo.
6 Esquema XML 1.0.
O XML Schema fornece uma variedade de mecanismos para extensibilidade e controle de versão: curingas, extensão de tipo, restrição de tipo, redefinição, grupos de substituição e atributos xsi: type. A construção de caractere curinga permite que os autores criem esquemas que sejam compatíveis para frente e para trás. Geralmente, um novo esquema usando curingas é compatível com versões anteriores, pois validará instâncias antigas e novas. A exceção são instâncias com conteúdo legal no curinga, mas não no novo conteúdo. Um exemplo pode ser um nome do meio que tenha estrutura ou dígitos. However, that scenario means that an author created a middle name instance in the middle name namespace according to one schema AND an author defined a new middle name in the same namespace according to a different schema. Arguably there is an authority over the namespace that will prevent such clashes and so in practice this exception won't happen. Alternatively, we can make a slightly different compatibility guarantee, which is the new schema is backwards compatible with validate old and new instance where new instances do not have any extensions in the defined namespaces. The old schema is forwards compatible because it will validate old and new instances - of course it sees these as current and future instances.
When an author creates a new version, a new schema can created by the replacement of wildcard(s) in the original, with an optional-element, optional-wildcard sequence, in the later schema. The new schema explicitly states the entire new content model, including everything from the original schema as well as the new explicit declaration for middle, and for that reason we call it a "Complete Respecification" of the type.
A new type declared using wildcards could be declared as an explicit <xs:restriction/> of the original type, because every document accepted by the new type is also accepted by the old. XML Schema's type <xs:restriction/> allows alteration of wildcards anywhere in the content model, like Complete Respecification, but allows the original type to be preserved. Alternatively, XML Schema's type extension mechanism <xs:extension/> @@provide ref to Recommendation@@ provides a different way of specifiying a modified type, in which the original content is not restated, but only the new elements are explicitly referenced. The differences are: (1) xs:extension allows new content only at the end of the model and (2) using wildcards as shown above, the original type will accept not only documents in the original language, but also documents containing the middle name, something that's not true in typical uses of xs:extension. Thus the schema author of new version of a type has 3 options outlined above: 1) Complete Respecification without explicit use of xs:restriction; 2) Complete Respecification with explicit use of xs:restriction; 3) xs:extension.
These mechanisms can be combined together. For example, a schema that supports new components in existing or new namespaces and supports multiple schema versions (described in @@) uses wildcards, type extension, and use of Extension elements in instances.
Given an extensibility point that allows different namespaces, the language designer and 3rd parties can now use different namespaces for their versions. In general, an extension can be defined by a new specification that makes a normative reference to the earlier specification and then defines the new content. No permission should be needed from the authors of the specification to make such an extension. In fact, the major design point of XML namespaces is to allow decentralized extensions. The corollary is that permission is required for extensions in the same namespace. A namespace has an owner; non-owners changing the meaning of something can be harmful.
Attribute extensions can be in any namespace because in XML schema, attributes do not have non-determinism (aka Unique Particle Attribution) constraints that elements do. In XML Schema, the attributes are always unordered and the model group for attributes uses a different mechanism for associating attributes with schema types than the model group for elements. We will discuss this important issue later in the finding.
7 Schemas for Version Identification Strategies.
7.1 #1: all components in new namespace(s) for each version.
Using XML Schema 1.0, the name owner might like to write a schema such as:

eBay Schema Versioning Strategy.
As of August 2015, the lowest supported version is 863 .
This topic describes eBay's versioning strategy for the Trading API (and Shopping API), which enables us to evolve the schema while maintaining backward compatibility for at least 18 months. This strategy is intended to address these concerns:
eBay adds new features every two weeks. If you update your client software less frequently, your software needs a way to handle unrecognized data from eBay. Over time, it becomes more difficult for eBay to support third-party software that is using outdated business logic or features. eBay needs a way to eventually drop support for outdated features. We understand that it may be difficult for you to update your software on short notice. To help you, eBay needs to maintain support for outdated features for some period of time, and we need to give you as much notice as possible before we completely stop supporting a feature.
In each release, we do our best to update the schema in a backward-compatible way. However, sometimes we need to make changes that aren't backward compatible:
As XML schema constructs are typed, any modification that would result in a type change is a potential incompatibility. As a very simple example, we might currently express a measurement or a count in integer values ( xs:int ), but in a future enhancement we might need a way to allow decimal fractions for the same value ( xs:double ). If your application is expecting a field to return an integer at runtime and we start returning a double instead, your application could fail. So, we need a way to avoid changing the type directly. Changing the multiplicity of an element is also a potential incompatibility. For example, we might currently allow a single URL field, but in a future enhancement we might allow repeating URL fields ( maxOccurs="unbounded" ). As some toolkits interpret repeating fields as arrays, this would be equivalent to a type change.
When such changes are necessary, we need a way to gracefully phase in the new approach and gracefully phase out the old one. (That is, we need to make changes without causing third-party applications to fail unexpectedly, and applications need to be designed to accommodate routine changes.) This approach is described below.

Impact of XML Schema Versioning on System Design.
(Strategies for Facilitating System Evolution)
Introdução.
Creating a new version of an XML Schema may have effects that ripple through many parts of a system. Managing these effects can be expensive. So it is worthwhile to examine ways to mitigate the costly ripple effects of new versions of a Schema.
Frequently, Schema versioning is considered in isolation from the rest of the system. However, as noted, Schema changes may impact other parts of a system, so we recommend that Schema versioning be part of an integrated system evolution plan. Schema versioning is one of the drivers for system evolution.
As a strategy for facilitating system evolution we focus on these three parts of a system - Schemas, instance documents, and applications. To treat these three parts in a holistic fashion we make the following recommendations:
Schema Design Recommendations:
Instance Document Design Recommendations:
Application Design Recommendations:
The rationale for each of these recommendations is explained over the course of this paper. But first we begin by defining the nature of the systems being targeted.
O sistema.
Problem Statement.
Categories of Schema Changes that Impact Instance Documents and Applications.
Note: There are many other kinds of changes that could occur in an XML Schema than those listed above. However, they are changes internal to the schema and have no manifestation in instance documents.
Below we discuss how to mitigate the impact of each of these changes.
1. Namespace-Aware Applications.
Most XML applications are "namespace aware". That is, the application is designed to process elements belonging to a specific namespace.
For example, an XML Stylesheet Language Transformations (XSLT) Processor is an application which understands the XSLT namespace: Concretely, this means that an XSLT Processor (application) knows how to process elements such as <template>, <for-each>, <if>, etc., provided the elements are associated with the XSLT namespace .
Changing namespaces results in breaking namespace-aware applications. This brings us to our first recommendation:
Recommendation 1: To avoid breaking namespace-aware applications with each new version of an XML Schema use the same namespace for all versions.
2. Place the New Version of a Schema at a New Location to Avoid Breaking Old Instance Documents.
Suppose that a new version of a XML Schema is created (using the same namespace, as described above). And the new version simply overwrites the old version. That is, the new version has the same filename and the same URL location as the old schema. Depending on the kinds of changes made, this may result in breaking all instance documents that were written to conform to the old Schema.
Recommendation 2: To prevent breaking old instance documents give the new Schema version a different filename or a different URL location or both.
3. Dealing with Change to an Element's Content Model.
A common occurrence when creating a new version of an XML Schema is to change an element's content. (The technical expression is: "change an element's content model")
For example, in a version 1 Schema the <location> element may have been declared to be comprised of <lat> and <lon> whereas in version 2 its contents may be <x> and <y>.
Suppose that an application receives an instance document which conforms to the latest version of the Schema. And let's suppose that the application is still coded to the previous version of the Schema. The application parses through the instance document and arrives, say, at the <location> element. How will the application recognize that location's content model has changed?
It would be useful if the application could consult the parser: "What's the type (content model) of <location>?" If the type is not one that it expects then the application must decide how to proceed.
How can we facilitate an application in recognizing an element's type? That is, how do we enable applications to determine the type of each element it encounters? Answer: the XML Schema must be designed to provide explicit type information.
Recommendation 3: To facilitate an application in recognizing that an element's content has changed, don't use anonymous types. Instead, use named types.
Exemplo. Do not design your Schema like this:
What is location's type? Answer: it is anonymous. This Schema is not designed to facilitate an application in obtaining type information.
Instead, design your Schema like this: What is location's type? Answer: the named type, locationType-x_y_version. Thus, this Schema is designed to facilitate an application in obtaining type information.
Suppose that an Schema designer follows Recommendation 3 and always uses named types. This will enable applications to query a parser for type information, e. g., "What's the type of <location>?" The parser will reply with: "the type is locationType-x_y_version". If this is a type that the application did not expect (i. e., was not coded to understand) then it will take appropriate steps (as described above).
Let's continue with the <location> example. Above we saw the motivation for using named types - it enables an application to easily discover an element's content model. Of course, if a new version of a Schema is created and <location>'s type is changed but the new type is given the same name as the old type, then it defeats the whole purpose of type information. This leads us to the next recommendation:
Recommendation 4: If you change a type when you create a new version of a Schema then give the type a different name.
Exemplo. Suppose that in the version 1 Schema <location> has this as its contents: <lat> and <lon>. The Schema declares this named type:
Now suppose that in the version 2 Schema the contents of <location> is changed to <x> and <y>. It is important to give a new name to location's type:
Thus, if a version 1 application receives a version 2 instance document then, when it parses down to the <location> element, it will be able to easily recognize that <location>'s content model has changed (it has changed from locationType to locationType-x_y_version).
3.b Localize Type Changes.
Suppose that the <location> element is nested within an <aircraft> element, e. g.,
Technically, the contents of <aircraft> has changed since the contents of <location> has changed. Should the type name for <aircraft> be changed? Answer: no. The reason is that we want to minimize changes. That is, we want an application to see as many familiar elements and types as possible. The aircraftType is a familiar type. It still has as its contents a <location> element. We want to preserve this familiarity.
Recommendation 5: Change the name of an element's type only if its immediate content has changed.
3.c Use a Version attribute.
Applications will find it useful to have an indication of whether it can expect changes as it processes an instance document. This can be accomplished using a version attribute on the root element.
Note that this is what XSLT does. As the XSLT technology has migrated to a new version, instance documents (i. e., XSLT documents) indicate which version is being used with a version attribute on the root element.
Recommendation 6: Use a version attribute on the root element. If an instance document is a compound document - that is, an assembly of XML fragments - then place a version attribute on the root of each fragment.
4. Effect of Shuffling Elements.
A new version of a Schema may make a change as simple as reordering the contents of an element. For example, in a version 1 Schema the order may be A, B, C, e. g.,
In the version 2 Schema the order may be changed to B, C, A, e. g.,
If an application is coded to expect a certain ordering of the data then the new version of the Schema will break the application. To avoid this an application should never depend on specific ordering of data. It should locate the data using the tags.
Recommendation 7: Applications should use the tag names to locate data in instance documents. Applications should be designed to anticipate that the order of tags may change.
5. Effect of Removing an Element or Attribute.
Creating a new version of an XML Schema may result in removing an element or attribute. Consider an application that has not been upgraded to the new version, and receives an instance document that conforms to the new version. The application must decide whether the lack of the element or attribute is catastrophic or whether it can live without the information. The action taken is application-specific (and is outside the scope of this paper).
6. Effect of Adding an Element or Attribute.
Creating a new version of an XML Schema may result in adding an element or attribute. Consider an application that has not been upgraded to the new version, and receives an instance document that conforms to the new version. The application must decide what to do with the additional information. Again, what action is taken is application-specific.
What to do when an Application Breaks.
The above recommendations will help mitigate breakage due to Schema changes. However, they do not guarantee that applications will not break. An old application may receive a new instance that is missing crucial information, or the content model of a crucial element may have changed to a type that cannot be dynamically understood.
To anticipate such occurrences it will be beneficial to institute a system protocol that specifies what actions should be taken by applications when breakage occurs. One possible protocol is for an application to respond to the sender with a fault message.
Recommendation 8: Define a system-wide protocol (e. g., fault reporting mechanism) to be used when an application is unable to process an instance document it receives from another application.
To minimize impact to existing instance documents and applications as new versions of XML Schemas are created, we make the following recommendations:
Recommendation 1: To avoid breaking namespace-aware applications with each new version of an XML Schema use the same namespace for all versions.
Recommendation 2: To prevent breaking old instance documents give the new Schema version a different filename or a different URL location or both.
Recommendation 3: To facilitate an application in recognizing that an element's content has changed, don't use anonymous types. Instead, use named types.
Recommendation 4: If you change a type when you create a new version of a Schema then give the type a different name.
Recommendation 5: Change the name of an element's type only if its immediate content has changed.
Recommendation 6: Use a version attribute on the root element. If an instance document is a compound document - that is, an assembly of XML fragments - then place a version attribute on the root of each fragment.
Recommendation 7: Applications should use the tag names to locate data in instance documents. Applications should be designed to anticipate that the order of tags may change.

A Flexible Model for Data Integration.
by Tim Ewald and Kimberly Wolk.
Summary: There are many challenges in systems integration for architects and developers, and the industry has focused on XML, Web services, and SOA for solving integration problems by concentrating on communication protocols, particularly in regard to adding advanced features that support message flow in complex network topologies. However, this concentration on communication protocols has taken the focus away from the problem of integrating data. Flexible models for combining data across disparate systems are essential for successful integration. These models are expressed in XML schema (XSD) in Web service–based systems, and instances of the model are represented as XML transmitted in SOAP messages. In our work on the architecture of the MSDN TechNet Publishing System (MTPS), we addressed three pitfalls. We'll look at what those pitfalls are and our solutions to them, in the context of a more general problem—that of integrating customer information.
Systems integration presents a wide range of challenges to architects and developers. Over the last several years, the industry has focused on using XML, Web services, and service-oriented architecture (SOA) to solve integration problems. Much of the work done in this space has concentrated on communication protocols, especially on adding advanced features designed to support messages flowing in complex network topologies. While there is undoubtedly some value in this approach, all of this work on communication protocols has taken focus away from the problem of integrating data.
Having flexible models for combining data across disparate systems is essential to a successful integration effort. In Web service–based systems, these models are expressed in XSD. Instances of the model are represented as XML that is transmitted between systems in SOAP messages. Some systems map the XML data into relational databases; some do not. From an integration perspective, the structure of those relational database models is not important. What matters is the shape of the XML data model defined in XSD.
There are three pitfalls that Web service–based data-integration projects typically fall into. All three are related to how they define their XML schemas. We confronted all three in our work on the architecture of the MSDN TechNet Publishing System (MTPS), the next-generation XML-based system that serves as the foundation for MSDN2. We will look at our solutions in the context of integrating customer information.
The Essential Data-Integration Problem.
Imagine you work at a large company. Your company has many outward-facing systems that are used by customers to accomplish a variety of tasks. For instance, one system offers customized product information to registered users who have expressed particular interests. Another system provides membership-management tools for customers in your partner program. A third system tracks customers who have registered to come to upcoming events. Unfortunately, the systems were all developed separately—one of them, by a separate company that your company acquired a year ago. Each of these systems stores customer-related information in different formats and locations.
This setup presents a critical problem for the business: It doesn't have a unified view of a given customer. This problem has two effects. First, the customer's experience suffers, because the single company with which they are doing business treats them as different people when they use different systems. For example, customers who have expressed a desire to receive information about a given product through e-mail whenever it becomes available have to express their interest in that product a second time, when they register for particular talks at an upcoming company-sponsored event. Their experiences would be more seamless if the system that registered them for an upcoming event already knew about their interest in a particular product.
Second, the business suffers, because it does not have an integrated understanding of its customers. How many customers who are members of a partners' program are also receiving information about products through e-mail? In both cases, the divisions between the systems with which the customer works are limiting how well the company can respond to its customers' needs.
Whether this situation arose because systems were designed and developed individually, without any thought to the larger context within which they operate, or because different groups of integrated systems were collected through mergers and acquisitions is irrelevant. The problem remains: The business must integrate the systems to improve the customer experience and their knowledge of who the customer is, and how best to serve them.
The most common approach to solving this problem is to mandate that all systems adopt a single canonical model for a customer. A group of architects gets together and designs the company's single format for representing customer data as XML. The format is defined using a schema written in XSD. To enable systems to share data in the new format, a central team builds a new store that supports it. The XSD data model team and store team deliver their solution to all the teams responsible for systems that interact with customers in some way and require that they adopt it. The essential change is shown in Figures 1 and 2.
Each system is modified to use the underlying customer-data store through its Web service interface. They store and retrieve customer information as XML that conforms to the customer schema. All of the systems share the same service instance, the same XSD data model, and the same XML information.
This solution appears to be simple, elegant, and good, but a naïve implementation will typically fail for one of three reasons: demanding too much information, no effective versioning strategy, and no support for system-level extension.
Demanding Too Much Information.
The first potential cause for failure is a schema and store that require too much information. When people build a simple Web service for point-to-point integration, they tend to think of the data their particular service needs. They define a contract that requires that particular data be provided. When a contract is generated from source code, this data can happen implicitly. Most of the tools that map from source code to a Web service contract treat fields of simple value types as required data elements, insisting that a client send it. Even when a contract is created by hand, there is still a tendency to treat all data as required. As soon as the service determines (by schema validation or code) that some required data is not present, it rejects a request. The client gets a service fault.
This approach to defining Web service contracts is too rigid and leads to systems that are very tightly coupled. Any change in the service's requirements forces a change in the contract and in the clients that consume it. To loosen this coupling, you need to separate the definition of the shape of the data a service expects from a service's current processing requirements. More concretely, the data formats defined by your contract should treat everything beyond identity data as optional. The implementation of your service should enforce occurrence requirements internally at run time (either using a dedicated validation schema or code). It should be as forgiving as possible when data is not present in a client request and degrade gracefully.
In the customer-information example, it is easy to think of cases where some systems want to work with customers, but do not have complete customer information available. For instance, the system that records a customer's interest in a particular product might only collect a customer's name and preferred e-mail address. The event registration system, in contrast, might capture address and credit-card information, too. If a common customer-data model requires that every valid customer record include name, e-mail, address, and credit-card information, neither system can adopt it without either collecting more data than it needs or providing bogus data. Making all the data other than the identity (ID number, e-mail address, and so forth) optional eases adoption of the data model, because systems can simply supply the information they have.
Figure 1. Three separate data stores, one per system (Click on the picture for a larger image)
By separating the shape of data from occurrence requirements, you make it easier to manage change in the implementation of a single service. It is also critical when you are defining a common XML schema to be used by multiple services and clients. If too much information is mandatory, every system that wants to use the data model may be missing some required piece of information. That leaves each system with the choice of not adopting the shared model and store, or providing bogus data (often, the default value of a simple programming-language type). Either option can be considered a failure.
Figure 2. A single data store and format (Click on the picture for a larger image)
You gain a lot of flexibility for systems to adopt the model by loosening the schema's occurrence requirements nearly completely. Each system can contribute as much data as it has available, which makes a common XML schema much easier to adopt. The price is that systems receiving data must be careful to check that the data they really need is present. If it is not present, they should respond accordingly by getting more data from the user or some other store, by downgrading their behavior, or—only in the worst case—generating a fault. What you are really doing is shifting some of the constraints you might normally put in an XML schema into your code, where they will be checked at run time. This shifting gives you room to change those constraints without revising the shared schema.
No Effective Versioning Strategy.
The second potential cause for failure is the lack of a versioning strategy. No matter how much time and effort is put into defining an XML schema up front, it will need to change over time. If schema, the shared store that supports them, and every system that uses them has to move to a new version all at once, you cannot succeed. Some systems will have to wait for necessary changes, because other systems are not at a point where they can adopt a revision. Conversely, some systems will be forced to do extra, unexpected work, because other systems need to adopt a new revision. This approach is untenable.
To solve this problem, you need to embrace a versioning strategy that allows the schema and store to move ahead independent of the rate at which other systems adopt their revisions. This solution sounds simple, and it is, as long as you think about XML schemas the right way.
Figure 3. A combination of stores (see Figures 1 and 2) (Click on the picture for a larger image)
Systems that integrate using a common XML schema view it as a contract. Lowering the bar for required data by making elements optional makes a contract easier to agree to, because systems are committing to less. For versioning, systems also need to be allowed to do more without changing schema namespace . What this means in practical terms is that a system should always produce XML data based on the version of the schema with which it was developed. It should always consume data based on that same version with additional information . This definition is a variation on Postel's Law: "Be liberal in what you accept, conservative in what you send." Arguably, this idea underlies all successful distributed systems technologies, and certainly all loosely coupled ones. If you take this approach, you can extend a schema without updating clients.
In the customer example, an update to the schema and store might add support for an additional optional element that captures the user's mother's maiden name for security purposes. If systems working with the old version generate customer records without this information, it's okay, because the element is optional. If they send those records to other systems that require this information, the request may fail, and that is okay, too. If new systems send customer data including the mother's maiden name to old systems, that is okay also, because they are designed to ignore it.
Happily, many Web service toolkits support this feature directly in their schema-driven marshaling plumbing. Certainly, the object-XML mappers (both the trusty XmlSerializer and the new XmlFormatter/DataContract) handle extra data gracefully. Some Java toolkits do, too, and frameworks that support the new JAX-WS 2.0 and JAXB 2.0 specifications will, also. Given that, adopting this approach is pretty easy.
The only real problem with this model is that it introduces multiple definitions of a given schema, each representing a different version. Given a piece of data—an XML fragment captured from a message sent on the wire, for instance—it is impossible to answer the question: "Is this data valid?" The question of validity can only be answered relative to a particular version of the schema. The inability to state definitively whether a given piece of data is valid presents an issue for debugging and, possibly, also for security. With data models described with XML schema, it is possible to answer a different and more interesting question: "Is this data valid enough?"
This question is really what systems care about, and you can answer it using the validity information most XML-based schema validators provide, which is a reasonable path to take in cases where schema validation is required, and it can be implemented with today's schema validation frameworks.
No Support for System-Level Extension.
The third potential cause for failure is lack of support for system-specific extensions to a schema. The versioning strategy based on the notion that a schema's definition changes over time is necessary to promote adoption, but it is not sufficient. While it frees systems from having to adopt the latest schema revision immediately, it does nothing to help systems that are waiting for specific schema updates. Delays in revisions also can make a schema too expensive for a system to adopt. The solution to this last problem is to allow systems that adopt a common schema to extend it with additional information of their own. The extension information can be stored locally in a system-level store (see Figure 3).
Figure 4. The same store (see Figure 3), with data formats in a shared store (Click on the picture for a larger image)
In this case, each system is modified to write customer data both to its dedicated store using its own data model and to the shared store using the canonical schema. It is also modified to read customer data from both its dedicated store and the shared store. Depending on what it finds, it knows whether a customer is already known to the company and to the system. Table 1 summarizes the three possibilities.
The system can use this information to decide how much information it needs to gather about a customer. If the customer is new to the company, the system will add as much information as it can to the canonical store. That information becomes available for other systems that work with customers. It may also store data in its dedicated store to meet its own needs. This model can be further expanded so that system-specific data is stored in the shared store, too (see Figure 4).
This solution makes it possible for systems to integrate with one another, using extension data that is beyond the scope of the canonical schema. To work successfully, the store and other systems need to have visibility into the extension data; in other words, it cannot be opaque. The easiest way to solve this problem is to make the extension data itself XML. The system providing the data defines a schema for the extension data, so other systems can process it reliably. The shared store keeps track of extension schemas, so it can ensure that the extension data is valid, even if it does not know explicitly what the extension contains. In the most extreme case, a system might choose to store an entire customer record in a system-specific format as XML extension data. Other systems that understand that format can use it. Systems that do not understand it rely on the canonical representation, instead.
When systems are independent, each controls its own destiny. They can capture and store whatever information they need, in whatever format and location they prefer. The move to a single common schema and store changes that. If adopting a common XML data format restricts a system's freedom to deliver required functionality, you are doomed to fail.
Using a combination of typed XML extension data in either a system-level or the shared store adds complexity, because you have to keep data synchronized. But it also provides tremendous flexibility. You can align systems around whatever combination of the canonical schema and alternate schemas you want. You can drive toward one XML format over time, but you always have the flexibility to deviate from that format to meet new requirements. This extra freedom is worth a lot in the uncertain world of the enterprise.
Table 1. The three possible cases of customer data.