homeyou

Todo espaço em branco, incluindo quebras de linha (Mac CR, Win CR/LF, Unix LF), caracteres TAB, e espaços normais, até mesmo entre elementos estruturais onde nenhum texto pode aparecer , é passado pelo analisador não-modificado para a aplicação (navegador, formatador, visualizador, conversor, etc). O analisador identifica o contexto no qual o espaço em branco foi encontrado (conteúdo do elemento, conteúdo de dados de caractere, ou conteúdo misto), se esta informação está disponível, eg de um DTD ou Schema. Isto significa que é a responsabilidade da aplicação decidir , o que fazer com tal espaço, e não do analisador.

Esta é uma das poucas mudanças radicais de SGML, onde todo espaço em branco em elemento de conteúdo foi descartada pelo analisador sem ter mesmo chegado perto da aplicação. Veja Por Quê? abaixo.

Existem dois tipos significativos de espaço em branco:

• Espaço em branco insignificante (espaço em branco descartável) o qual ocorre entre elementos estruturais em elemento de conteúdo. Este é um espaço que ocorre onde somente outros elementos são permitidos, onde texto nunca ocorre. É geralmente inserido automaticamente por um editor ou manualmente por um autor para ajudar com a clareza visual da marcação, e frequentemente não tem nada a ver com espaçamento que você vê quando o documento é processado ou formatado. Em XML, este espaço será passado à aplicação (em SGML ele foi reprimido, razão pela qual você pode colocar todo aquele espaço extra em documentos mais velhos HTML e não se preocupar);

• Espaço em branco significante que ocorre dentro dos elementos os quais podem conter apenas texto (conteúdo de dados de caractere, como um title ) HTML) ou texto e marcação postos juntos (eg parágrafos). Em XML, este espaço ainda passará para a aplicação exatamente como era em SGML.

Em ambos os casos, é a responsabilidade da aplicação lidar com o espaço corretamente (XSLT2, por exemplo, oferece um instrução strip-space para especificar como lidar com os mesmo). O analisador deve portanto informar a aplicação que espaço em branco ocorreu no elemento de conteúdo, se puder detectá-lo, para que possa ser então descartado. (Usuários de SGML reconhecerão que esta informação não está no ESIS , mas está no Grove .)

<chapter> 
  <title> 
   My title for
   Chapter 1. 
  </title> 
    <para> 
text 
    </para> 
</chapter>
    

No exemplo acima, a aplicação receberá todos as digitações de quebras de linha, TABs, e espaços entre os elementos bem como àqueles embutidos no capítulo do título. É o trabalho da aplicação, não do analisador, em decidir quais tipos de espaço em branco descartar e quais reter. Muitas aplicações XML têm opções configuráveis que permitem programadores e usuários controlar como tais espaços em branco são manuseados.

Peter Flynn escreve:

Por que?

Em SGML, uma DTD é compulsória, sempre. Um analisador portanto sempre sabe com antecedência se espaço em branco ocorreu em um elemento de conteúdo (e pode portanto ser descartado) ou em conteúdo misto ou dados de caractere (onde deve ser preservado). XML permite processamento sem a DTD ou Schema, onde pode ser impossível dizer se o espaço deveria ser descartado ou não, então a regra geral era imposta que todo espaço em branco deve ser notificado para a aplicação.