XML é uma dessas coisas ubíquas [1], e é uma coisa bastante fashion, todo mundo usa sem mesmo saber ou se questionar porque; é como James Joyce, ninguém tem coragem de admitir que não leu Ulisses, mas a verdade é que ninguém leu [2]. Mas os amantes da literatura inglesa que me perdoem: não saber XML (de verdade) tem conseqüências muito maiores que não ter lido Ulisses.
É relativamente simples aprender a utilizar XML, e isso é uma grande coisa, mas também é um grande problema, pois todo mundo acha que sabe o que está fazendo sem se dar ao trabalho de ler alguma coisa por uma hora que seja.
Não vou entrar neste texto em detalhes básicos sobre XML, vou assumir que você conhece o básico, caso você sinta que precisa saber mais, eu aconselho as seguintes referências: [W3S] e [REE].
Vamos analisar alguns casos de coisas realmente muito estúpidas que as pessoas fazem usando XML e vocês entenderão um pouco melhor o que eu quero dizer.
Processando o XML sem um parser
Uma das idéias que alguém pode ter quando necessita processar um XML recebido de algum lugar é utilizá-lo sem um parser XML, obtendo o conteúdo dos elementos ou atributos por manipulação de strings [3]. Vou contar dois casos sobre isso.
Um deles era um sistema onde uma configuração era feita via XML e em um momento um elemento foi comentado no XML com <!-- -->, o sistema não funcionava como esperado e assim ficou por semanas, até que por acidente eu removesse o elemento da configuração em vez de comentar e tudo funcionou. O sistema utilizava uma linguagem de script [4] para fazer parse [5] do XML e buscava os elementos pelo nome da tag com uma busca de string. Claro que a busca não deixava de encontrar o elemento se ele estivesse dentro de um comentário, algo perfeitamente válido de fazer em XML. Exemplificando:
<?xml version="1.0" encoding="utf-8" ?>
<configuracoes>
<!--<item1>Dado de configuração</item1>-->
...
</configuracoes>
Se procurarmos o dado entre os tags <item1> e </item1> acharemos o dado mesmo dentro do comentário, por outro lado se procurarmos o dado usando um parser com o XPath /configuracoes/item1 só obteremos o dado se ele existir e não estiver comentado.
O outro caso é o de uma API de um sistema que retornava alguma informação em XML. Na integração dos sistemas, o cliente pegou o dado que interessava para ele no XML com uma busca de string. Em um momento no futuro algo mudou na geração do XML, não o seu formato mas detalhes como espaços e quebras de linha entre tags que definiam elementos, mas é claro a busca pelo string não levava em consideração que um XML válido poderia ter variações nestes detalhes e a integração entre os sistemas parou de funcionar.
Quando se pensa no XML como se fosse uma string, esta string pode estar em inúmeras formas diferentes para um XML com todos os elementos e atributos idênticos. O seguinte XML:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<president order="44" start="2009">
<name>Barak Hussein Obama</name>
<address>Avenida Pensilvânia</address>
</president>
<president order="43" start="2001">
<name>George Walker Bush</name>
<address>Algum lugar no Texas</address>
</president>
</root>
é absolutamente equivalente a:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<president start="2009" order="44">
<name>Barak Hussein Obama</name><address>Avenida Pensilvânia</address>
</president>
<president start="2001" order="43" >
<name>George Walker Bush</name><address>Algum lugar no Texas</address>
</president>
</root>
ou ainda equivalente à
<?xml version="1.0" encoding="UTF-8"?>
<root>
<president start="2009" order="44">
<address>Avenida Pensilvânia</address> <name>Barak Hussein Obama</name>
</president>
<president start="2001" order="43" >
<address>Algum lugar no Texas</address> <name>George Walker Bush</name>
</president>
</root>
no sentido de que quase todos XPath feitos para obter um elemento ou atributo obterão os mesmos valores [6].
Este é o clássico problema do XML não canonicalizado. A única maneira de garantir uma uniformidade de strings contendo XMLs equivalentes é os XML estarem na forma canônica [7], nem sempre um XML está na forma canônica, e em geral não está, assim sendo não podemos assumir nada sobre coisas como espaços entre tags, quebras de linha, ordem de atributos dentro de um elemento, etc (lembre-se que como o XML muitas vezes é utilizado na interface entre os sistemas nem sempre recebemos XML cujo formato está sob nosso controle). A prevenção disso é simples, utilize um parser, não faça buscas "criativas" por strings ou mesmo com expressões regulares para obter conteúdo do XML.
Definindo XML por exemplos
É muito comum você solicitar uma especificação de um XML que o seu sistema receberá e receber como resposta, pasme, um exemplo do XML. Esta é uma péssima maneira de especificar um XML, posso dar inúmeros motivos.
Para começar, nela você não sabe quais elementos são opcionais:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<president start="2009" order="44">
<name>Barak Hussein Obama</name>
<address>Avenida Pensilvânia</address>
</president>
</root>
Se o elemento address for opcional, como saberemos, ou dito de outra forma: como isso nos será informado? Se deixarmos de colocá-lo não se saberá que ele existe, se colocamos não há nada no exemplo que diga que ele é opcional. Podemos incluir um outro presidente e num colocar e no outro não, mas e se o elemento fosse um XML onde o elemento president não pudesse ser repetido, como faríamos então? Poderíamos criar dois exemplos, um com o elemento address e um sem, e eles teriam de ser considerados em conjunto:
<?xml version="1.0" encoding="UTF-8"?> |
<?xml version="1.0" encoding="UTF-8"?> |
Mas e se tivermos dois elementos em seguida que são mutuamente exclusivos? Nenhuma combinação de exemplos que fizessemos poderia explicitar este fato:
<?xml version="1.0" encoding="UTF-8"?> |
<?xml version="1.0" encoding="UTF-8"?> |
Podemos ver que um exemplo tem o elemento wife e outro o elemento fiancee, mas nada nos diz se eles são mutuamente exclusivos, ou são apenas dois exemplos onde cada um deles mostra um elemento opcional cada um. Para dar conta desta ambigüidade teríamos de introduzir regras obrigando a explorar todas as combinações possíveis de elementos opcionais, se tivermos muitos elementos opcionais haveria muitos exemplos. Além do mais teríamos de analisar todos os exemplos e deduzir que esta combinação nunca ocorre.
Outro motivo para não usar exemplos é que não sabemos, quais elementos podem ser repetidos e quantas vezes podem:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<president start="2009" order="44">
<name>Barak Hussein Obama</name>
<address>Avenida Pensilvânia</address>
<address>Outro endereço</address>
</president>
</root>
Se o elemento address aparecer um repetido duas vezes significa o que? Que ele pode repetir duas vezes ou mais? Ou mesmo quantas vezes se queira?
Para definir um XML de maneira não ambígua através de exemplos precisaríamos de muitos exemplos, e interpretar estes exemplos caso sejam muitos poderia ser bastante difícil.
Acho que já provei que usar exemplos é ruim, e usar exemplos junto com explicações é impreciso, pois explicações são sujeitas a interpretação. Existem várias maneiras de especificar um XML de maneira precisa, você pode usar um DTD, um DDML (antigamente chamado de X-Schema), um XML schema (XSD), um Relax NG (muito usado no Japão), um Schematron ou um Examplotron. Estas são todas maneiras não ambíguas de descrever um XML. Algumas dessas maneiras são bastante interessantes, leves e inteligentes, para maiores detalhes veja as referências [VLI1] e [VLI2].
Mesmo que a partir do exemplo possa-se criar algum esquema que permita a validação do XML, pode-se chegar a um caso onde a definição informal caia em um esquema não determinístico. Um esquema não determinístico ocorre quando existe uma ambigüidade na definição do esquema se por exemplo você especificar no esquema que pode haver digamos um elemento repetido seguido de um elemento opcional, seguido do mesmo elemento repetido novamente. Se o elemento opcional não existir não existe maneira de saber se o elemento repetido é o primeiro ou o segundo. Tratarei de esquemas em um outro artigo.
O fato de você especificar a forma do XML com alguns destes métodos não significa que você vá validá-lo a todo momento, pois isso acarretaria um grande overhead [9], mas na hora de processar o XML você pode escrever os XPaths com muita segurança pois sabe o que esperar, quando eles poderão retornar nulo ou não etc, isso torna seu sistema muito menos propenso a erros (se o esquema for obedecido, trataremos disso depois).
É interessante lembrar que os esquemas especificam a forma e não a semântica do XML, ou seja o significado de cada elemento, isso deve ser acordado entre as partes. Isso muitas vezes leva a problemas que não são resolvidos pelos esquemas, especialmente quando lembramos que XMLs são strings, por exemplo, em que unidade está um dado numérico de um elemento ou qual o seu separador decimal (ponto ou virgula), etc.
Mudando seu esquema de maneira a quebrar aplicações que usem o seu XML
Vamos lembrar que o X do XML significa extensível, assim sendo podemos tranquilamente colocar um elemento novo no XML que enviávamos para alguém sem que a aplicação tenha muita chance de quebrar.
Para que isso seja possível tanto quanto quem usa como quem recebe o XML tem de ter certo bom senso. Quem recebe não precisa validar o XML quanto ao esquema combinado, se desejar uma validação basta criar um esquema que valide os XPaths que serão utilizados pelo seu sistema, que pode ser uma validação bem mais leve, a não ser que seja desejável saber se existe alguma informação nova no XML que pode ser aproveitada.
Quem envia deve evitar mudanças disruptivas, não mude nomes de atributos e elementos, não torne elementos antes obrigatórios opcionais (embora o contrário seja permitido), claro que nem sempre isso é possível, mas pode ser evitado por um planejamento mais cuidadoso do seu esquema; um versionamento cuidadoso do esquema e um aviso prévio da mudança ajudam em casos como estes.
Dados no nome da tag e não no conteúdo do elemento
Este é um caso derivado do primeiro pois se fosse feita uma definição não ambígua do XML isso não teria acontecido. Os nomes das tags e propriedades devem ser definidos previamente e nunca criados dinamicamente de acordo com dados, pois os dados podem mudar elementos e propriedades com nomes imprevisíveis, e que não podem portanto ter seu conteúdo lido com XPath.
Imagine um web service que devolve um XML e neste XML pode haver um tag que indique uma condição de erro. Mas imagine que este web service apenas encapsula outra maneira de fornecer acesso à informação desejada (que poderia perfeitamente ter sido usada, mas XML tem um ar mais moderno e bonito). Agora imagine que o criador do web service tem pouco ou nenhum conhecimento de como o sistema funciona e quais estados de erro ele pode fornecer.
Em vez de criar um elemento com nome conhecido onde serão colocados os dados do erro, como mensagem, nome e código, foi montado um elemento definido por um tag cujo nome era montado pela mensagem de erro, como por exemplo algo assim:
<?xml version="1.0" encoding="utf-8" ?>
<root>
...
<DatabaseAcessError/>
...
</root>
Parece inofensivo, não é mesmo? Mas lembre-se que se não se sabe qual o domínio dos dados que podem vir, ou seja quais erros podem ocorrer não se poderá escrever um XPath para verificar se o XML reporta um erro. Por exemplo Podemos ter algo assim:
<?xml version="1.0" encoding="utf-8" ?>
<root>
...
<DatabaseTimeoutError/>
...
</root>
Ou inúmeros outros tags que não sabemos quais podem ser. Não poderemos sequer identificar que ocorreu um erro. Mesmo que efetuemos testes para descobrir o domínio (quais tags de erro podem vir) nunca poderemos ter certeza de ter achado todos, além do mais não é simples forçar erros a ocorrerem.
Esta maneira de fazer é estúpida mesmo que se soubesse o domínio e isso fosse especificado em um esquema, pois o XPath fica complicadíssimo, e podem ser necessários vários XPaths, além do fato de que sempre que uma mensagem nova for necessária o formato do XML deve mudar para dar conta do novo tag.
Uma maneira muito mais sensata seria criar um elemento com um tag como erro ou parecido para que um XPath simples possa ser escrito para verificar se foi reportado um erro ou não, até gerar um XML assim é mais simples
<?xml version="1.0" encoding="utf-8" ?>
<root>
...
<error message="Database access error" code="12"/>
...
</root>
Existem vezes que este tipo de situação não é tão óbvia, algumas vezes os dados que o XML carrega tem como origem uma base de dados, que muitas vezes pode conter dados com cardinalidade desconhecida, domínios desconhecidos, etc. Normalmente em bases de dados as tabelas filhas relacionadas por uma chave estrangeira não tem limitação em relação a cardinalidade, e alguns campos que poderiam ser normalizados em tabelas filhas devido a um domínio restrito de valores não o são, permitindo violar esta condição tendo outros valores. Assim a tentativa de colocar os dados em um XML muitas vezes leva a impressão que o XML será gerado de uma maneira e ele não é, tendo valores não previstos ou cardinalidades não previstas. Isso não é desculpa para semelhante tolice, mas geralmente é usado como desculpa.
O mais kafkiano da situação é que quando os sistemas não funcionam o fornecedor de um XML desse tipo geralmente argumenta que os dados estão lá, basta ler o XML para ver que estão. Infelizmente o computador não sabe ler, ele só pode interpretar XMLs através de XPaths. São momentos assim que à vezes me fazem considerar trabalhar em uma área mais séria, por exemplo como curandeiro vodu, onde quem der uma resposta deste gênero certamente receberia um feitiço para transformar o indivíduo em zumbi.
Encapsulando XMLs dentro de XMLs da maneira errada
Este é o meu caso preferido, pois mostra que mesmo a incompetência poder ser muito criativa. Imagine que você recebe um XML e este XML foi composto por um XML "envelope" que encapsula outro XML, mas na hora de montar o XML, o XML interno foi colocado dentro do outro usando-se a propriedade InnerText em vez de InnerXML, neste caso você obtém algo assim:
<?xml version="1.0" encoding="utf-8" ?>
<root>
<received_data date="20090109">
<root><president><name>Barak Hussein Obama</name><
/president></root>
</received_data>
</root>
A única maneira de acessar os dados desse híbrido seria ler o conteúdo do elemento received_data e carregá-lo em um XML para então poder acessar os dados dele usando XPaths. Se este XML fosse montado de maneira inteligente (usando o InnerXML ou alguma maneira semelhante), ele seria assim:
<?xml version="1.0" encoding="utf-8" ?>
<root>
<received_data date="20090109">
<root>
<president>
<name>Barak Hussein Obama</name>
</president>
</root>
</received_data>
</root>
Neste caso podemos acessar todos os dados diretamente com XPath.
Mas existem vezes que você não vai querer que o XML encapsulado esteja dentro do outro como um XML. Por exemplo se seu XML for encapsular outro que não está sob seu controle, o motivo é que o XML a ser encapsulado pode ser mal formado, além disso se necessitar guardar o XML exatamente como veio para fins de registro terá de manter o prólogo e todos os espaços e quebras de linha (que podem ser úteis em uma auditoria) e você não pode ter um prólogo no meio de um XML. Mas neste caso não use esta maneira de fazê-lo, o XML fica bastante ilegível desta maneira. Utilize a maneira padrão que o XML disponibiliza para isso, uma secção CDATA.
Determinando a relação entre elementos pela sua posição
Se você tiver elementos que estão relacionados entre si, fazendo parte de um grupo e que se agrupam coloque-os dentro de um outro elemento. Não faça coisas do tipo:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<name>Barak Hussein Obama</name>
<address>Avenida Pensilvânia</address>
<name>George Walker Bush</name>
<address>Algum lugar no Texas</address>
</root>
Porque isto é errado e na verdade estúpido? Por vários motivos, em primeiro lugar porque não existe maneira simples de escrever um XPath para obter um elemento, ou dado um elemento obter outros agrupados com ele.
Além disso se após um exercício intelectual extremo se conseguir escrever este XPath o acréscimo de um elemento a mais com novos dados pode deixar este XPath inválido (lembre-se que o X de XML quer dizer extensível, ou seja as coisas podem mudar). Por exemplo se acrescentássemos o número ordinal do presidente:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<order>44</order>
<name>Barak Hussein Obama</name>
<address>Avenida Pensilvânia</address>
<order>43</order>
<name>George Walker Bush</name>
<address>Algum lugar no Texas</address>
</root>
Uma maneira mais sensata seria esta:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<president order="44">
<name>Barak Hussein Obama</name>
<address>Avenida Pensilvânia</address>
</president>
<president order="43">
<name>George Walker Bush</name>
<address>Algum lugar no Texas</address>
</president>
</root>
Existem outras maneiras de fazer este agrupamento (como usando atributos iguais para o mesmo grupo), mas esta certamente é uma das que gera os XPath mais simples, se eu quiser dado o nome obter o endereço basta fazer o seguinte XPath: /root/president[name='George Walker Bush']/address.
Além do mais um dos princípios que devem nortear a criação de um XML é que ele deve poder ser facilmente lido por um humano (afinal poderíamos criar protocolos binários muito mais eficientes se não fosse isso) e desta maneira fica fácil entender o agrupamento dos dados (ao contrário do caso de usarmos um atributo de igual valor para agrupar os dados).
Agrupando elementos repetidos pelo nome
Quando temos um elemento repetitivo que podemos ter de identificar isoladamente basta repetir o elemento e usar um atributo para identificar cada repetição. Infelizmente, alguns acham que devem colocar esta informação no nome da tag do elemento. Desta maneira completamente estranha:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<president>
<name order="44">Barak Hussein Obama</name>
<address>Avenida Pensilvânia</address>
<child1>Malia Ann Obama</child1>
<child2>Natasha Obama</child2>
</president>
</root>
Novamente temos o problema do XPath. Se quisermos um XPath para saber quantos filhos um presidente tem, não poderemos fazê-lo de maneira simples. Se quisermos iterar pelos elementos dos filhos não poderemos fazer isso a não ser contruindo múltiplos XPaths um para cada ítem, etc, etc, etc. Acho que você já entendeu.
Este erro é análogo a má normalização de uma tabela base de dados, se temos um elemento repetitivo mesmo que saibamos quantas vezes ele se repete, ele deve ir para uma tabela relacionada [8]. E bases mal normalizadas como fonte dos dados que gerarão o XML muitas vezes são a origem deste engano. Novamente, isso não é desculpa.
A maneira mais inteligente de fazer este XML seria usar apenas um elemento repetido e se necessário usar uma ou mais propriedades ou elementos internos a eles para identificá-los, como já dissemos acima, assim:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<president>
<name order="44">Barak Hussein Obama</name>
<address>Avenida Pensilvânia</address>
<child order="1">Malia Ann Obama</child>
<child order="2">Natasha Obama</child>
</president>
</root>
Ou variações sobre este tema, como agrupando os elementos child dentro de um elemento children por exemplo.
Usando XML sem necessidade.
Este é talvez o pior e mais comum dos erros. Sempre que se fala em algo seja um arquivo de configuração, um protocolo ou uma linguagem de domínio específico (DSL) já se vai escrevendo um XML, em muitos casos isso é pesado, desnecessário e simplesmente incapacidade ou preguiça de escrever um parser.
Existem casos onde o XML é uma opção interessante, ele substituiu com sucesso o EDIFACT. Mas existem inúmeros protocolos em uso hoje em dia que não usam XML: FTP, SMTP, POP3 e mesmo o HTTP são protocolos essencialmente texto, na base de perguntas e respostas muito curtas. O uso de XML em casos assim traria um sobrepeso [9] desnecessário. Imagine uma aplicação minúscula onde um arquivo de configuração muito simples poderia ser usado e você usa um XML, dependendo do caso o parser DOM pode ser maior que o seu programa e a memória usada por ele também. isso é particularmente importante em sistemas embarcados.
Existem algumas alternativas em uso hoje, por exemplo o YAML [ANA] [WIK1] que tem um parser muito leve e é ideal para arquivos simples de configuração.
Quando se usa AJAX está cada vez mais comum usar o JASON [CRO] [WIK2] como alternativa ao XML no transporte de dados. O JSON (leia-se Jason) não é uma linguagem de markup, ele é mais uma maneira de serialização que descreve os objetos, strings números e arrays da maneira como eles seriam escritos em JavaScript. Isso torna muito fácil processar os dados no cliente ao contrário do caso quando se usa XML.
Notas
[1]. Isso mesmo ubíqua. Ubíqua significa está em vários lugares ao mesmo tempo. Usei o termo para esclarecer uma questão; normalmente você lê ou ouve o termo pervasivo, bem, pervasivo é um barbarismo (termo estranho à língua), mais especificamente um estrangeirismo (termo adaptado de outra língua) e mais especificamente ainda um anglicismo (estrangeirismo derivado do inglês). Não sou purista a ponto de ser contra emprestarmos termos de outras línguas quando não existe termo adequado no português (tente traduzir bootstrap), mas sou ferrenhamente contra utilizar termos assim quando existem equivalentes na nossa língua, como checar (quando o correto é verificar), atachar (anexar), embed (incorporar, embutir, embarcar), escopo (âmbito), workshop (seminário), coffee break (pausa para o café), deletar (apagar), abduzir (sequestrar), etc. Muitos argumentarão que palavras como abajour (lucivélo antigamante), envelope (sobrecarta), piquenique (convescote), todos são estrangeirismos que substituiram termos existentes no fim do século XIX, quando o medo era dos galicismos. Mas no passo atual onde somos bombaredeados com a língua inglesa e com o avanço das comunicações, televisão, Internet, etc., se não paramos com isso todas as línguas convergirão para o inglês. Que eu me recorde a igreja católica admite como milagre (dos três que a tradição exige, ou dos dois que a lei canônica exige para a canonização) o milagre da ubiqüidade e não o milagre da pervasividade (isso deve até ser pecado). Para encerrar de vez este assunto, talvez eu possa aceitar salvar no lugar de gravar, mesmo porque existe o verbo salvar em português com um sentido que é similar, mas você acha mesmo que deletar é aceitável no lugar de apagar, uma palavra tão comum da nossa própria língua? Minha intenção é simples, eu aceito que a língua mude e incorpore termos de outras línguas, não me importo de falar CD, DVD, Blu-ray, mas eu não quero que o português desapareça, como quase já aconteceu com o Gaélico (falado na escócia e na Irlanda) e o Galês (falado no país de Gales) e tantos outros idiomas das ilhas britânicas devorados pelo inglês tão ubíquo.
[2]. Eu não li, fui até o solilóquio (outra palavra difícil, leia-se monólogo) e quase morri de falta de ar e de incompreensão das orações subordinadas depois de duas páginas sem pontuação nenhuma. E olhe que eu já conegui ler coisas muito longas e complicadas.
[3]. Viu? Eu uso termos estrangeiros quando não existe nada melhor.
[4]. Viu? De novo.
[5]. E de novo.
[6]. Com exceção de XPaths que usem a posição absoluta (com a função Position do XPath) ou relativa (com XPath Axes como following-sibling, preceding-sibling, etc.) de atributos ou elementos, o que é absolutamente incomum. Por exemplo, o XPath /root/president[1]/*[1] (ou, por exemplo o XPath equivalente a ele /root/president[position()=1]/*[1] ) retornará o elemento name no primeiro caso e o elemento address no segundo.
[7]. Um XML na forma canônica deve estar em UTF-8, não ter a declaração XML, as quebras de linha devem ser por LF (ASCII 10) apenas, os elementos vazios devem ser descritos pelos tags de abertura e fechamento (como em <tag></tag> e não por <tag/>), os atributos devem estar na ordem alfabética, namespaces desnecessários são removidos, etc. Alguns dos processamentos para canonicalizar um XML implicam em saber seu esquema, pois envolvem colocar atributos default onde eles são opcionais e normalizar os valores dos atributos. Para mais detalhes sobre a forma canônica de um XML consulte [REE]. Ironicamente a rigor um XML na forma canônica não é um XML (não tem a daclaração XML [W3C2]), em tese isso não deveria gerar ambiguidade pois o encoding é sempre UTF-8 e na ausência de versão do XML assume-se 1.0, por outro lado a canonicalização de XMLs de outra versão não é coberta no padrão de canonicalização. Não se veem muitos XMLs na forma canônica por aí, normalmente eles são usados para fins de comparação entre XMLs e porque na verdade não são muito úteis, mesmo após a canonicalização dois XMLs equivalentes podem ter diferenças, como namespaces e prefixos, a versão antiga do padrão reescrevia os prefixos de modo a canonicalizá-los, mas como é comum haver XMLs atributos com XPaths referenciando partes do XML esse procedimento foi abandonado [W3C3].
[8]. Porque? Bem, em primeiro lugar se este número mudar teremos de mudar a estrutura da base. Além disso, se o item repetido aparecer uma vez só estaremos com os campos para os dados que nunca aparecerão com espaço reservado. E finalmente porque é difícil iterar por estes dados repetidos porque cada campo tem um nome diferente.
[9]. No caso de overhead, ou sobrepeso eu mantenho uma atitude intermediária, às vezes uso um às vezes outro.
Referências
[W3S]: REFSNES DATA. XML Tutorial. Disponível em: <http://www.w3schools.com/xml/default.asp>. Acesso em: 15 jan. 2009.
[REE]: REES, L. C. Learn XML in 11.5 minutes. Rev. 1.2. Disponível em: <http://www.geocities.com/SiliconValley/Peaks/5957/10minxml.html>. Acesso em: 15 jan. 2009.
[W3C1]: BOYER, John. Canonical XML. Version 1.0. W3C Recommendation. 15 mar. 2001. Disponível em: <http://www.w3.org/TR/xml-c14n>. Acesso em: 28 jan. 2009.
[W3C2]: BOYER, John. No XML Declaration. In: _______. Canonical XML. Version 1.0. W3C Recommendation. 15 mar. 2001. Disponível em: <http://www.w3.org/TR/xml-c14n#NoXMLDecl>. Acesso em: 28 jan. 2009.
[W3C3]: BOYER, John. No Namespace Prefix Rewriting. In: _______. Canonical XML. Version 1.0. W3C Recommendation. 15 mar. 2001. Disponível em: <http://www.w3.org/TR/xml-c14n#NoNSPrefixRewriting>. Acesso em: 28 jan. 2009.
[OGB]: OGBUJI, Uche.Introducing XML canonical form. Disponível em: <http://www.ibm.com/developerworks/xml/library/x-c14n/>. Acesso em: 15 jan. 2009.
[VLI1]: VLIST, Eric van der. XML.com: Comparing XML Schema Languages. 2001. Disponível em: <http://www.xml.com/lpt/a/884>. Acesso em: 15 jan. 2009.
[VLI2]: VLIST, Eric van der. XML.com: Comparing XML Schema Languages. 2001. Disponível em: <http://www.xml.com/pub/a/2001/12/12/schemacompare.html>. Acesso em: 15 jan. 2009.
[ANA]: ANANIEV, Alexander. XML Alternatives and YAML. [S.l.], November 19th, 2008. Disponível em <http://myarch.com/xml-alternatives-and-yaml>. Acesso em: 14 mar. 2009.
[WIK1]: YAML. In: Wikipedia. Disponível em <http://en.wikipedia.org/wiki/YAML>. Acesso em: 14 mar. 2009.
[CRO]: CROCKFORD, Douglas. JSON: The Fat-Free Alternative to XML. Boston, December 6, 2006. Disponível em <http://www.json.org/fatfree.html>. Acesso em: 14 mar. 2009.
[WIK2]: JSON. In: Wikipedia. Disponível em <http://en.wikipedia.org/wiki/JSON>. Acesso em: 14 mar. 2009.
Airton, precisamos tomar um cafe.
Marque e entre em contato avisando.
Posted by: Shintaro | 06/03/2009 at 08:27