Apêndice D. Futuras normas relacionadas com SGML

Índice
D.1. Extensible Markup Language (XML) 1.0
D.2. Document Object Model (DOM)
D.3. CSS e XSL
D.4. Extensible Linking Language (XLL) e Extended Pointers (XPointer)
D.5. NameSpaces in XML (XML Namespace)
D.6. Vector Markup Language
D.7. Simplified Markup Language - SML

Desde o início desta tese já se passaram quatro anos. E foram quatro anos bem efervescentes. A indústria de software acordou para o SGML e para as normas relacionadas com a estruturação de conteúdos (normalmente, para a internet). Nos últimos dois anos, tem havido uma explosão de ideias, os interesses multiplicaram-se bem como as pessoas neles envolvidas.

Este apêndice surge, ao terminar a escrita da dissertação, para fazer o ponto da situação actual. Será fácil concluir que, apesar da proliferação de ideias e de propostas para novas normas, os conceitos são os mesmos, a filosofia SGML está lá: formato neutro, estruturação de conteúdos, independência relativamente à apresentação.

A lista de especificações SGML bem como o número de propostas de novas normas submetidas ao W3C é enorme. Aqui, apresentam-se algumas das mais relevantes e aquelas para as quais se prevê um maior impacto e desenvolvimento, que andam indubitavelmente a gravitar em torno do XML

As especificações que se descrevem estão ainda em diferentes estágios de desenvolvimento (na sua maioria ainda inacabadas), podem, por isso, ser alteradas. Isto não implica que não estejam a ser utilizadas; muito pelo contrário, há especificações ainda no primeiro nível de desenvolvimento já implementadas.

Actualmente, o W3C considera quatro níveis de desenvolvimento para as propostas de normalização que lhe são submetidas. Apresenta-se a seguir uma lista dos níveis de desenvolvimento e correspondentes especificações.

Recomendação

Significa que a especificação está estável, contribui para uma evolução da tecnologia e é suportada pelos membros do W3C que apoiam a sua aplicação.

  • Extensible Markup Language (XML) 1.0

  • Document Object Model (DOM) Level 1

  • Cascading Style Sheets Level 1 (CSS1)

  • Cascading Style Sheets Level 2 (CSS2)

  • NameSpaces in XML (XML Namespace)

Recomendação Proposta

Significa que a especificação está a ser revista pelos membros do W3C.

  • Neste momento não há nenhuma relacionada com o XML.

Rascunho

Significa que a especificação pode ser alterada em qualquer altura, substituída ou simplesmente posta de lado; este tipo de material não deve ser usado como referência podendo, no entanto, ser citado como "trabalho em desenvolvimento".

  • Extensible Stylesheet Language (XSL)

  • XML Linking Language (XLL)

  • XML Pointer Language (XPointer)

Notas

Significa que se trata de uma especificação submetida ao W3C pelo público, ou por algum membro; não foi submetida num "Call for proposals"; por ter interesse ou qualidade é publicada e mantida para discussão.

  • XML Query Language (XQL)

  • XML Data (XML-Data)

  • Schema for Object-oriented XML (SOX)

  • Vector Markup Language (VML)

  • Simplified Markup Language (SML)

No tabela seguinte, sintetiza-se o domínio de acção das propostas mais relevantes:

Tabela D-1. Domínios de acção

EspecificaçãoEstiloTransformaçãoSelecção
SGMLDSSSLDOMXQL
XMLXSLXSLXLL
SMLCSS1SOXXPointer
 CSS2  

A utilização combinada das várias linguagens é possível: pode-se montar um sistema escolhendo uma proposta de cada categoria tendo o cuidado de verificar se se está a escolher a mais adequada ao fim em causa. O XML representa a linguagem de anotação mais versátil podendo combinar-se com qualquer uma das outras categorias. O SGML também se poderá combinar com algumas das outras (com o DSSSL é o mais usual) mas com algumas adaptações. O SML, de momento não passa de uma ideia, de certa maneira retrógada, como iremos ver mais à frente.

Algumas destas propostas são explicadas a seguir.

D.1. Extensible Markup Language (XML) 1.0

E então surgiu o XML... E surge a pergunta: porquê XML e não SGML? Sim, porque o XML é apresentado como um subconjunto do SGML. À partida parece que se vai perder algo adoptando um e não o outro.

A resposta encontra-se na história e desenvolvimento da informática. O SGML surgiu já há mais de 10 anos e teve de conviver com os condicionalismos da época o que se traduz actualmente num pequeno subconjunto de características que deixaram de fazer sentido e que apenas atrapalham.

A linguagem de anotação XML foi definida pelo W3C [http://www.w3c.org], para a produção de conteúdos estruturados para a Internet.

As próximas secções darão resposta à questão que fica agora no ar: Porquê mais uma norma para a Internet?

D.1.1. O Passado

O XML não é mais do que um subconjunto do SGML (Capítulo 4).

O SGML e o XML são mais do que linguagens de anotação, são meta-linguagens; permitem a definição de novas linguagens. Por outro lado, o HTML, a linguagem de anotação mais conhecida para a produção de páginas para a Internet, está definida em SGML. É uma linguagem concreta, não é possível estendê-la a não ser que se altere a sua definição inicial (o que a transformaria noutra linguagem).

O XML não tem esta limitação. Sendo uma meta-linguagem, permite em qualquer momento o acrescentar de novos elementos à linguagem. Na prática, isto traduz-se numa linguagem aberta que nos permite especificar qualquer coisa com o nível de detalhe que pretendermos.

Neste momento, o HTML continua a ser a linguagem mais utilizada na Internet mas, irá ser gradualmente substituído pelo XML.

D.1.2. Porquê XML?

O crescimento espantoso da Internet, nomeadamente do serviço WWW, nos últimos anos, é um facto que se deve principalmente à possibilidade de distribuir, facilmente e a baixos custos, informação e aplicações, a qualquer utilizador, em qualquer parte do mundo. À medida que a informação que se coloca na Internet se vai tornando cada vez mais complexa e o número de utilizadores vai crescendo, as limitações das tecnologias e normas actuais vão-se tornando cada vez mais evidentes.

A limitação na construção de páginas WWW deve-se principalmente ao facto do HTML possuir apenas um conjunto fixo e pré-definido de etiquetas com o qual se pode definir a estrutura e a aparência de uma página WWW. Foi esta limitação e a impossibilidade de de criar estensões à linguagem que tornou a criação de uma nova norma desejável. Nalgumas aplicações, principalmente onde uma publicação electrónica de alta qualidade e desempenho é o objectivo a atingir, tem-se vindo a adoptar o SGML para a produção e manutenção de conteúdos; as páginas WWW são depois geradas automaticamente, partindo destes conteúdos. No entanto, o SGML é complexo e de difícil aprendizagem o que fará com que seja apenas utilizado por comunidades que possuam um elevado nível técnico e, consequentemente, não tenha uma grande aceitação por parte dos utilizadores normais.

Nos últimos tempos, as aplicações distribuídas em geral, vieram realçar a falta de uma norma para a transferência de dados estruturados. Apesar dos esforços e do dinheiro investido essa norma não surgiu. Os problemas surgem quando diferentes aplicções querem interagir; normalmente, cada uma tem o seu próprio formato para comunicar dados que é diferente do da outra.

Para resolver estes problemas, foi criado o XML. O XML oferece um método estruturado e consistente para descrever e transferir informação. A melhor característica que possui, herdada do SGML, é a separação do formato visual da informação propriamente dita. Isto faz com que o XML seja a linguagem ideal para a produção de conteúdos textuais (independência de plataformas de hardware e software, longevidade, ...). Duas aplicações XML podem enviar e receber informação livremente sem preocupações com o formato dessa informação, a informação contida num documento XML auto-descreve-se.

O XML foi concebido tendo uma série de objectivos em vista:

  • Deve ser directamente utilizável na Internet - os utilisadores devem ser capazes de ver páginas XML da mesma maneira que vêem páginas HTML.

  • Deve suportar uma série de aplicações: editores, browsers, sistemas de gestão de bases de dados, ... No entanto, o principal objectivo é a produção de conteúdos estruturados para a Internet.

  • Deve ser compatível com o SGML - já existem muitos conteúdos em SGML e para quem os produziu a compatibilidade entre os dois é crítica.

  • A escrita de programas para processar documentos XML deve ser simples.

  • O número de características opcionais deve ser reduzido a um mínimo, pois quantas mais houver mais problemas de compatibilidade poderão surgir.

D.1.3. XML: características

Como já foi dito, o XML acaba por ser um subconjunto do SGML. Uma vez que o SGML já foi detalhadamente descrito nesta tese, podemos descrever o XML enunciando quais as características do SGML que foram deixadas de fora.

Assim, há simplificações ao nível das declarações no DTD e da funcionalidade esperada.

Ao nível do DTD foram retiradas as seguintes características:

  • Inclusões e exclusões.

  • O operador &.

  • Ao nível de entidades apenas se pode ter um nível de indireccionamento.

    As entidades do tipo carácter não fazem parte de nenhuma distribuição uma vez que foi adoptado o Unicode como conjunto de caracteres base [Unicode].

A diferença mais marcante entre o SGML e o XML é a importância dada à validação do documento com o DTD, como se pode ver na próxima secção.

D.1.3.1. Válido versus Bem-Estruturado

Para qualquer linguagem, é necessário que haja uma entidade que verifique se um dado documento escrito nessa linguagem está de acordo com a gramática e especificações dessa linguagem. No caso presente, o DTD corresponde à gramática e o parser ao verificador.

No entanto, o XML foi pensado para suportar aplicações "Web" e, em muitos casos, o DTD e as respectivas verificações podem tornar-se um fardo bem pesado. Então criaram-se dois patamares de validação: o documento válido e o documento bem-formado. Um documento diz-se válido se tiver um DTD associado e se o texto do documento está de acordo com as especificações no DTD; um documento diz-se bem-formado se obedecer às seguintes condições:

  • Tiver um ou mais elementos.

  • Há apenas um elemento (o elemento raíz) para o qual nem a anotação de início nem a anotação de fim estão dentro de qualquer outro elemento.

  • Todas as outras anotações têm que estar aninhadas correctamente.

  • Todas as entidades usadas no documento têm de estar definidas em XML ou no DTD.

Podemos ver agora dois exemplos: o primeiro de um documento bem estruturado e o segundo do mesmo documento mas agora com o DTD associado ilustrando o conceito de documento válido.


Exemplo D-1. Um documento bem estruturado

<RECEITAS>
  <TITULO> O Meu Livro de Receitas </TITULO>
  <RECEITA ORIGEM="Portugal">
    <TITULO> Bolo </TITULO>
    <INGREDIENTE> 500g de farinha </INGREDIENTE>
    <INGREDIENTE> 200g de açucar </INGREDIENTE>
    <INGREDIENTE> 300g de manteiga </INGREDIENTE>
  </RECEITA>
</RECEITAS>


Exemplo D-2. Um documento válido

<!DOCTYPE RECEITAS [
<!ELEMENT RECEITAS    (TITULO,RECEITA*)>
<!ELEMENT TITULO      (#PCDATA)>
<!ELEMENT RECEITA     (TITULO,INGREDIENTE*)>
<!ELEMENT INGREDIENTE (#PCDATA)>
<!ATTLIST RECEITA ORIGEM CDATA #IMPLIED>
]>
<RECEITAS>
  <TITULO> O Meu Livro de Receitas </TITULO>
  <RECEITA ORIGEM="Portugal">
    <TITULO> Bolo </TITULO>
    <INGREDIENTE> 500g de farinha </INGREDIENTE>
    <INGREDIENTE> 200g de açucar </INGREDIENTE>
    <INGREDIENTE> 300g de manteiga </INGREDIENTE>
  </RECEITA>
</RECEITAS>

Terminamos a apresentação do XML com um pequeno conjunto de regras que permitem transformar qualquer documento SGML num documento XML (lembrar que em XML não necessitamos do DTD pelo que basta que as anotações estejam de acordo com as regras do XML para que o documento possa ser considerado um documento XML):

  • Acrescentar no início do documento a seguinte instrução de processamento:

    <?xml version="1.0" encoding="ISO-8859-1"?>

  • Fechar todas as anotações iniciadas (não há anotações opcionais - o SGML permitia a ausência de anotações nalguns casos).

    Todos os elementos vazios passam de:

    "...discutido em <Referencia citeid='plima'></Referencia> ..." 
    a
    "...discutido em <Referencia citeid='plima'/> ..."

    O que irá facilitar muito a vida ao parser (ao encontrar "/>", sabe que o elemento corrente termina ali).

  • Todos os valores de atributos devem estar dentro de aspas ou plicas.