O Futuro do XML Agora você conhece o XML. É verdade que a estrutura é um pouco complexa e o DTD possui diversas opções para definir o que o documento pode conter. Mas isso não é tudo.
Considere um setor para o qual a troca de dados é importante, como o bancário. Os bancos usam sistemas de propriedade para rastrear transações internamente, mas se usarem um formato XML comum na Web, deverão descrever as informações da transação para outra instituição ou aplicativo (como Quicken ou MS Money). Claro, eles também podem representar dados em páginas da Web. Para sua informação: esta tag não existe. Chama-se OFEX, Bolsa Financeira Aberta.
Sob certas circunstâncias, se o IE 4 em um PC encontrar uma tag <SOFTPKG>, uma função será iniciada para dar ao usuário a oportunidade de atualizar o software instalado. Se você usa Windows 98, pode ter visto essa situação, mas não sabia que se trata de uma aplicação XML.
Aqui temos três aplicativos XML que parecem diferentes das máquinas de somar, máquinas de escrever e lápis que Andy Grove viu na década de 1970. Mas, semelhantemente aos aplicativos que eventualmente apareceram nos PCs, os benefícios do XML podem ser descritos geralmente como: "Quando você usa tags legíveis por humanos e máquinas para descrever seus dados, coisas boas acontecem.
Essas coisas boas acontecem.
"? Eu não faço ideia. Mas também não sei como será a próxima geração de programas no meu PC. Contanto que os dados sejam marcados dessa forma, diferentes aplicativos poderão ser gerados.
Você está começando a pensar até onde isso pode se expandir?
Temos muitas aplicações práticas de XML para discutir e irei abordá-las em um futuro próximo. Como somos todos usuários da Internet, o futuro será o XSL (Extensible Style Language-
linguagem de estilo extensível).
Aliás, essa receita é mesmo da minha mãe e é excelente. Se for usar, adicione mais meia xícara de coco ralado.
Estou escrevendo isso porque realmente me importo com o que você pensa de mim. Minha preocupação é esta: se você leu minha introdução ao XML e está pronto para começar a escrever seus próprios documentos XML. Então você começa a procurar um DTD já estabelecido para representar suas informações. Você encontra um, conforme mostrado abaixo:
<!ATTLIST fn
%attr.lang;
valor CDATA #FIXED "TEXT">
<!ENTITY % attr.img "
img.type CDATA #REQUIRED
img.data ENTITY #REQUIRED">
Logo de cara você acha que Jay deve ser um idiota. Ele não disse nada sobre ATTLIST e ENTITY - sejam lá o que fossem.
Então vamos falar sobre isso, primeiro com um pouco de paciência.
As linhas acima podem não parecer boas, mas na verdade não são nada. Eles são usados em DTDs para definir atributos e entidades em documentos XML. Qualquer pessoa que conheça HTML sabe disso muito bem. Atributos são entradas com tags HTML que descrevem as tags com mais precisão. No <img src="my.gif" height="20" width="20"> que aparece frequentemente, existem dois atributos: altura e largura. Como você verá mais adiante, o uso de atributos em documentos XML é muito semelhante.
Também não há nada de novo sobre entidades. Se você já usou o &, já conhece o básico. Uma string cercada por & e ponto e vírgula representa outro caractere ou conjunto de caracteres. (Uma lista completa de entidades ISO está disponível aqui.)
É claro que atributos e entidades em XML têm outras funções. Isso inevitavelmente introduz sintaxe, embora não muito. Depois de saber disso, trabalhar com documentos XML será fácil.
Receitas simplificadas
Se você ler minha introdução ao XML, lembrará que os ingredientes de uma receita são representados por tags simples, como <item>2 xícaras de farinha</item>. Depois de escrever esse artigo, eu estava navegando pela web e encontrei outro documento XML sobre receitas. Os elementos da receita são os seguintes:
<ingredient amount="2" units="cups">farinha</ingredient>
Esta abordagem tem um benefício prático: facilita o controle dos dados. Na primeira abordagem, a tag <item> é usada para armazenar diversas informações diferentes. Se eu quisesse extrair uma lista de ingredientes sem as quantidades de cada ingrediente, não faria isso.
Posso obter funcionalidade semelhante usando a seguinte estrutura:
<item>farinha
<quantity>2</quantity>
<units>xícaras</units>
Isso pode ser resolvido, mas há dois problemas: Primeiro, o elemento item contém conteúdo misto: texto e outras marcações. Rapidamente descobri que essa estrutura deveria ser evitada sempre que possível. A segunda é que os marcadores quase não têm significado independente. É difícil imaginar uma situação em que existam apenas unidades, mas nenhum componente real. Esses itens podem ser descritos de forma simples, prefiro pensar neles como propriedades.
A primeira coisa a notar é que os nomes dos atributos, quantidades e unidades só têm significado quando processados por uma aplicação que pode traduzi-los.
O DTD deve ser informado para permitir isso antes de ser incluído em um documento válido. Para o elemento ingrediente acima, incluímos apenas o seguinte código no DTD:
<!ELEMENT ingrediente #PCDATA>
<!ATTLIST quantidade de ingrediente CDATA #REQUIRED>
<!ATTLIST unidades de ingrediente CDATA #REQUIRED>
A primeira linha parece familiar – definições de elementos padrão que você verá em qualquer DTD. Cada linha ATTLIST contém as seguintes informações:
<!ATTLIST quantidade de ingrediente CDATA #REQUIRED>
Este é o elemento ao qual o atributo está anexado.
<!ATTLIST quantidade de ingrediente CDATA #REQUIRED>
O nome do atributo é definido aqui.
<!ATTLIST quantidade de ingrediente CDATA #REQUIRED>
Defina o tipo de atributo aqui. CDATA significa dados de caracteres. Significa que o processador pode obter o texto dentro do atributo.
<!ATTLIST quantidade de ingrediente CDATA #REQUIRED>
A última parte define o valor padrão do atributo. Você pode usar um valor numérico real, como 3. Dessa forma, o valor do atributo para comprimento de espaço em branco em XML será 3. O valor inserido substituirá o valor padrão.
No exemplo acima não defini uma quantidade específica, mas utilizei a palavra-chave XML #REQUIRED. Diz ao processador que o atributo secundário deve conter um valor. Se estiver em branco, o documento não será processado.
O valor padrão possui duas palavras-chave adicionais. A primeira é #FIXED - se o valor do atributo permanecer o mesmo em todo o documento. Suponha que eu defina um atributo de tag de imagem e todas as imagens sejam do mesmo tamanho, como 100*50 pixels. Posso definir o atributo assim no DTD:
<!ATTLIST comprimento da imagem CDATA #FIXED "100 px">
<!ATTLIST largura da imagem CDATA #FIXED "50 px">
Outra palavra-chave é #IMPLIED, indicando que a propriedade pode conter um valor ou estar vazia.
Vejamos os tipos de atributos.
Se você decidir escrever seu próprio DTD, você pode querer um livro que explique o XML de todas as combinações em uma instrução ATTLIST. Mas se você pegar emprestado o DTD, poderá conhecer apenas CDATA e três outros atributos.
O primeiro é a identificação. Requer que o valor do atributo não se repita no documento. Qualquer pessoa que já tenha utilizado um banco de dados sabe da necessidade de identificadores exclusivos. A instrução DTD ATTLIST se parece com isto:
<!ATTLIST element_name attribute_name ID #REQUIRED>
É difícil imaginar o tipo de atributo ID sem o valor padrão #REQUIRED. Nesse caso, quaisquer IDs duplicados ou vazios forçarão o processador a retornar um erro. O ID deve começar com uma letra ou sublinhado e não pode conter espaços.
O tipo NMTOKEN também usa as regras de nomenclatura acima. Mas a duplicação é permitida. É utilizado como garantia de passagem de dados para a aplicação. A maioria das linguagens de programação, incluindo Java e JavaScript, não pode ter espaços nos nomes dos módulos. Na maioria dos casos, é melhor garantir que as propriedades cumpram as suas regras.
Finalmente, existem tipos de enumeração, que não requerem palavras-chave específicas. Em vez disso, use o símbolo "|" para colocar o valor entre parênteses, por exemplo:
<!ATTLIST irmão (irmão | irmã) #REQUIRED>
Essa abordagem poderá ser usada se houver um número limitado de valores de atributos possíveis.
Você não acha que o curso de hoje é chato, então continue lendo!