Normas Web – Tecnologias Futuraspaf/proj/Set2004/i970375-Normas Web.pdf · actual como o HTML,...

Normas Web – Tecnologias Futuras

2003 / 2004

970375 Sérgio Lopes

Departamento de Engenharia Informática Setembro de 2004

Orientador: Engº Paulo Proença


ISEP – Instituto Superior de Engenharia do Porto ii

Prefácio

O presente relatório apresenta o trabalho desenvolvido no âmbito da disciplina de

Projecto, do 5º ano da Licenciatura em Engenharia Informática – Computadores

e Sistemas, do Instituto Superior de Engenharia do Instituto Politécnico do

Porto.

A disciplina de Projecto configura-se como a etapa final de um longo percurso de

cinco anos curriculares. Embora não seja possível aplicar todos os conhecimentos

adquiridos ao longo do curso, sem dúvida que a sua frequência me proporcionou

as capacidades e experiência necessárias para levar a cabo este projecto.

O processo de desenvolvimento deste relatório iniciou-se com uma pesquisa

inicial pela web em busca da informação e recursos necessários. Após a obtenção

de material necessário, foi realizado um estudo preliminar que me permitisse

analisar a pertinência, adequabilidade e qualidade da informação encontrada.

Depois dessa selecção, estudei mais aprofundadamente o material seleccionado, o

que me permitiu ter uma ideia mais concreta do que representam as normas web,

bem como a sua relevância para a web de amanhã. Esse estudo permitiu-me

também começar a organizar e estruturar ideias e partir para o desenvolvimento

propriamente dito. Todo o desenvolvimento, aliás, foi paralelamente

acompanhado por contínua pesquisa, visto que a cada passo dado na construção

do relatório, novas dúvidas e necessidades surgiam, o que obrigava a um

permanente estudo e crescimento ao nível do conhecimento de cada área

estudada.


ISEP – Instituto Superior de Engenharia do Porto iii

Agradecimentos

Sendo este projecto o culminar de um longo trajecto académico, devo os meus

agradecimentos a todos aqueles que, não só contribuiram para a realização do

presente relatório, mas especialmente para todos aqueles que ao longo dos anos

me honraram com a sua amizade. Assim sendo, além de agradecer obviamente ao

Engº Paulo Proença por me ter dado a oportunidade de realizar este projecto,

agradeço a:

Minha Mãe e meu Pai, por estar onde estou;

Luís Romão e Paulo Ferreira, porque há amizades que vêm de longe;

José Gonçalves, Leandro Soares, Luís Marques, Rui Silva, Susana Santos, porque

o ano de 1997 foi único;

João Guiomar, José Santos, Ricardo Teixeira, Valter Silva, porque 1996 também

me trouxe pessoas fantásticas;

Ana Gonçalves, porque nem tudo em 1998 foi mau;

Marta Lopes, porque felizmente também podemos escolher a família;

Márcia Sousa e Mónica Oliveira, porque a amizade não tem barreiras nem

fronteiras;

Eduardo Covelinhas e Márcia Pinho, porque Lisboa também tem coisas boas;

Quéli Costa, por tudo!

Sandra Rodrigues, pela paciência e atenção;

Andreia Sacramento e Goreti Araújo, porque as coisas boas da vida surgem de

onde menos se espera;

Cláudio Morgado, Hugo Antunes e João Tomás, porque também há loucura

saudável;


ISEP – Instituto Superior de Engenharia do Porto iv

Hugo Costa e Pedro Alves, porque há fortalezas que se deitam abaixo;

Paulo Calçada, porque nem sempre é dia santo na loja quando o patrão está fora;

Filipe Murteira e Sandrina Martins, porque até no fim do mundo se encontram

amigos;

Mónica Ferreira, porque há embrulhos que escondem verdadeiras surpresas;

Jaime Ventura e Paulo Lourenço, porque me aturam todos os dias.


ISEP – Instituto Superior de Engenharia do Porto v

Resumo

O presente relatório encontra-se dividido em nove partes, em que o primeiro,

oitavo e nono capítulos se referem, respectivamente, à Introdução, Conclusão e

Bibliografia.

O segundo capítulo, Normas Web, faz a primeira apresentação ao conceito de

normas web, e discute a sua utilização na web de hoje e o conceito de

conformidade com as normas.

O terceiro capítulo apresenta o órgão regulador das normas web, o World Wide

Web Consortium e várias aspectos com ele relacionados, como a sua missão,

organização e objectivos. O capítulo contém também a apresentação de algumas

das suas tecnologias mais proeminentes, sob um ponto de vista mais formal.

O quarto capítulo, Normas Actuais, descreve com maior pormenor as normas e

tecnologias que actualmente predominam e sustentam o desenvolvimento web

actual como o HTML, XHTML, XML, CSS, DOM e ECMAScript.

O quinto capítulo, Benefícios das Normas, discute quais as vantagens que a

adopção das normas web como elemento basilar do desenvolvimento de projectos

web num ambiente profissional pode trazer. Discutem-se as vantagens na

acessibilidade de conteúdos, na estabilidade, no desenvolvimento de projectos e os

vários benefícios técnicos, financeiros e sociais que a adopção das normas pode

trazer a uma organização.


ISEP – Instituto Superior de Engenharia do Porto vi

O sexto capítulo, Adopção das Normas, sugere formas de abordagem às normas

web e de como as inserir no processo de desenvolvimento de uma forma segura e

integrada, apresentando tecnologias, métodos, procedimentos e técnicas para a

sua implementação.

O sétimo capítulo discute duas tecnologias que poderão ser usuais na construção

de documentos web no futuro, bem como uma nova filosofia para a web, a Web

Semântica.


ISEP – Instituto Superior de Engenharia do Porto vii

Índice

Prefácio .............................................................................................................................. ii

Agradecimentos............................................................................................................... iii

Resumo .............................................................................................................................. v

Índice................................................................................................................................ vii

Índice de Figuras............................................................................................................ xii

Índice de Tabelas...........................................................................................................xiii

Índice de Listagens ....................................................................................................... xiv

1. Introdução ................................................................................................................ 1

2. Normas Web ............................................................................................................ 3

2.1. Como funcionam as normas web........................................................................ 4

2.2. Porquê separar conteúdo de apresentação ........................................................ 5

2.3. Como saber se um sítio está em conformidade ................................................. 6

2.4. O que significa não estar em conformidade....................................................... 6

2.5. Fuga à conformidade e mitos associdados......................................................... 6

2.5.1. Mito nº 1: Páginas em conformidade pouco atraentes ...................................... 7

2.5.2. Mito nº 2: As normas aumentam o tempo de desenvolvimento .......................... 8

2.5.3. Mito nº 3: Todos os visitantes utilizam o Internet Explorer ................................ 9

2.5.4. Mito nº 4: Não é possível criar páginas iguais em todos os browsers ................ 11

3. World Wide Web Consortium............................................................................ 12

3.1. Acerca do World Wide Web Consortium............................................................ 12

3.2. Fundação do W3C.............................................................................................. 13

3.3. Missão do W3C .................................................................................................. 13

3.4. Objectivos do W3C ............................................................................................ 14

3.4.1. Acesso Universal .......................................................................................... 14


ISEP – Instituto Superior de Engenharia do Porto viii

3.4.2. Web Semântica................................ ................................ ............................. 14

3.4.3. Web de Confiança......................................................................................... 14

3.5. O Papel do W3C ................................................................................................. 14

3.5.1. Visão........................................................................................................... 15

3.5.2. Design......................................................................................................... 15

3.5.3. Normalização............................................................................................... 15

3.6. Princípio de Design da Web............................................................................... 16

3.6.1. Interoperabildade......................................................................................... 16

3.6.2. Evolução...................................................................................................... 16

3.6.3. Descentralização.......................................................................................... 16

3.7. Actividades do W3C ........................................................................................... 17

3.8. Algumas Recomendações do W3C.................................................................... 18

3.8.1. (X)HTML....................................................................................................... 19

3.8.2. CSS ................................ ................................ ................................ ............. 20

3.8.3. XForms 1.0.................................................................................................. 20

3.8.4. XML................................ ................................ ................................ ............. 20

3.8.5. DOM ........................................................................................................... 21

3.8.6. MathML 2.0.................................................................................................. 21

3.8.7. PNG................................ ................................ ................................ ............. 22

3.8.8. SVG 1.0....................................................................................................... 22

3.8.9. SMIL 2.0...................................................................................................... 22

3.8.10. Web Semântica................................ ................................ ............................. 22

3.8.11. XML-Signature e XML Encryption ................................................................... 23

3.8.12. P3P 1.0........................................................................................................ 23

3.8.13. Voice Framework.......................................................................................... 23

3.8.14. Linhas de Orientação para a Acessibilidade na Web......................................... 24

3.9. Desafios para o futuro ...................................................................................... 24

3.9.1. Assegurar o acesso à web através de vários dispositivos ................................. 24

3.9.2. Promover as melhores prácticas .................................................................... 25

3.9.3. Coordenação com as organizações internacionais de regulação....................... 26


ISEP – Instituto Superior de Engenharia do Porto ix

3.9.4. Atenção à diversidade cultural....................................................................... 26

3.9.5. Encorajar a investigação ............................................................................... 26

3.10. A Organização do W3C ................................................................................. 26

3.10.1. Neutralidade................................................................................................ 27

3.10.2. Coordenação................................................................................................ 27

3.10.3. Consenso .................................................................................................... 27

3.11. Essência do W3C ........................................................................................... 28

3.11.1. Acesso Universal .......................................................................................... 28

3.11.2. Web Semântica................................ ................................ ............................. 28

3.11.3. Confiança .................................................................................................... 29

3.11.4. Interoperabilidade........................................................................................ 29

3.11.5. Evolução...................................................................................................... 30

3.11.6. Descentralização.......................................................................................... 30

3.11.7. Melhor multimédia ....................................................................................... 30

4. Normas actuais....................................................................................................... 31

4.1. HTML 4.0 - HyperText Markup Language ........................................................ 31

4.2. XML 1.0 - Extensible Markup Language ........................................................... 32

4.3. XHTML 1.0, 1.1 e Modularização ...................................................................... 33

4.4. CSS - Cascading Style Sheets ............................................................................ 35

4.5. DOM 1 - Document Object Model Level 1........................................................ 35

4.6. ECMA Standards ................................................................................................ 36

4.6.1. O que é o ECMA ........................................................................................... 36

4.6.2. O que faz .................................................................................................... 36

4.6.3. ECMAScript, o JavaScript normalizado ............................................................ 37

5. Benefícios das normas ........................................................................................... 38

5.1. Acessibilidade .................................................................................................... 38

5.1.1. Para o software ............................................................................................ 38

5.1.2. Para as pessoas............................................................................................ 39

5.2. Estabilidade ....................................................................................................... 40

5.3. Benefícios para uma empresa ........................................................................... 40


ISEP – Instituto Superior de Engenharia do Porto x

5.3.1. Custos poupados durante do desenvolvimento ............................................... 41

5.3.2. Custos poupados durante a manutenção........................................................ 42

5.3.3. Custos poupados no dia a dia ....................................................................... 43

5.3.4. Aumentar a audiência do sítio ....................................................................... 44

5.3.5. Melhorar a imagem produz retorno financeiro ................................................ 45

5.3.6. Estar um passo adiante................................................................................. 45

6. Adopção das normas ................................ ................................ ............................. 47

6.1. Melhorar o layout de um sítio com o uso das normas ..................................... 47

6.1.1. Layout baseado em tabelas........................................................................... 48

6.1.2. Layout baseado em CSS ................................................................................ 48

6.1.3. Exemplo de utilização de tabelas para layout.................................................. 49

6.2. Decidir qual o método a escolher. .................................................................... 51

6.3. Escolhendo as normas ...................................................................................... 51

6.3.1. Escolher um método de layout. ................................ ................................ ..... 51

6.3.2. XHTML ou HTML........................................................................................... 52

6.4. Exigir o melhor .................................................................................................. 52

6.5. Educar a equipa de desenvolvimento ............................................................... 53

6.5.1. Nunca foram devidamente ensinados no seu uso ............................................ 53

6.5.2. As ferramentas utilizadas não produzem código standard............................... 54

6.5.3. “É demasiado difícil” ................................ ................................ ..................... 55

6.6. O que fazer com os sítios já existentes ............................................................ 56

6.7. Aplicar as normas em sítios web novos ............................................................ 56

6.8. Validação para controlo de qualidade .............................................................. 57

6.8.1. O que é a validação...................................................................................... 57

6.8.2. A validação é uma parte importante do controlo de qualidade......................... 58

6.8.3. Compreender o resultado das ferramentas de validação.................................. 59

7. Normas Emergentes e Futuras ........................................................................... 60

7.1. XForms............................................................................................................... 60

7.1.1. Formulários web .......................................................................................... 60

7.1.2. Aplicações de render de XForms .................................................................... 61


ISEP – Instituto Superior de Engenharia do Porto xi

7.1.3. Exemplo práctico ......................................................................................... 62

7.1.4. XForms, alternativa de futuro ........................................................................ 65

7.2. SVG, Scalable Vector Graphics .......................................................................... 66

7.2.1. Curta história do SVG ................................................................................... 66

7.2.2. O SVG ganha cada vez mais apoio ................................................................. 66

7.2.3. Legibilidade é uma grande vantagem................................ ............................. 68

7.2.4. Gráficos baseados em XML fazem sentido...................................................... 68

7.2.5. Documentos SVG e a largura de banda........................................................... 69

7.2.6. SVG e a comunidade de dispositivos móveis ................................................... 70

7.2.7. SVG e a Web................................................................................................. 71

7.2.8. Formato de futuro ........................................................................................ 72

7.3. Web Semântica .................................................................................................. 73

7.3.1. A forma correcta de pesquisar....................................................................... 74

7.3.2. Na web........................................................................................................ 75

7.3.3. Resource Description Framework................................................................... 76

7.3.4. Porque não usar apenas XML? ....................................................................... 78

7.3.5. Vocabulários ................................................................................................ 78

7.3.6. O que pode significar o RDF.......................................................................... 79

7.3.7. Linguagens de Ontologia .............................................................................. 79

7.3.8. OWL, Linguagem de Ontologia para a Web ................................ ..................... 82

7.3.9. Porquê OWL ................................................................................................. 82

7.3.10. As três sub-linguagens OWL ......................................................................... 83

8. Conclusão................................................................................................................ 85

9. Bibliografia................................ ................................ ................................ ............. 88


ISEP – Instituto Superior de Engenharia do Porto xii

Índice de Figuras

Figura 1 - Arquitectura web para o futuro................................................................. 19

Figura 2 - Tabela HTML ................................ ................................ ............................. 50

Figura 3 - Estrutura interna de Tabela HTML ........................................................ 50

Figura 4 - Formulário Xform....................................................................................... 65


ISEP – Instituto Superior de Engenharia do Porto xiii

Índice de Tabelas

Tabela 1 - Métodos de Layout ................................ ................................ ..................... 47


ISEP – Instituto Superior de Engenharia do Porto xiv

Índice de Listagens

Listagem 1 – Código XForms...................................................................................... 63

Listagem 2 - Modelo de dados XForms................................ ................................ ..... 64

Listagem 3 - Código RDF ............................................................................................ 76


ISEP – Instituto Superior de Engenharia do Porto 1

1. Introdução

Norma.

Podemos encontrar o seu significado em qualquer dicionário que tenhamos à mão.

Resumindo, pode ser sinónimo de regra de procedimento, de princípio, de

preceito, de direcção, de modelo, de lei.

Convivemos com normas e regras a cada segundo, porventura sem sequer nos

apercebermos que cumprimos algumas delas. Desde as leis da física que

determinam o tempo que veremos ao levantarmos a persiana de manhã, passando

pelas regras de trânsito que devemos cumprir a caminho do emprego, até às

regras de comportamento social que faz com que mantenhamos o nosso lugar na

fila de espera, enquanto respeitosamente aguardamos a nossa vez para pagar o

almoço.

Será que o mesmo se passa com a World Wide Web?

Claramente. Às normas que regem a web, como também designaremos a World

Wide Web, chamamos de web standards, ou normas web. Atrás referi que, por

vezes, não temos consciência da existência de determinadas normas. As normas

web são disso um bom exemplo. São estas normas que estão por trás das páginas

que consultamos diariamente. São, pode dizer-se, os blocos constructores da

informação que diariamente nos chega através de navegadores ou aplicações

similares fornecendo-nos formas de a estruturar, de a apresentar e de a



manipular. São estas normas que me proponho estudar e apresentar neste

relatório.

A escolha deste tema deveu-se sobretudo aos anos de experiência profissional que

possuo nesta área. Como tal, desde cedo tomei contacto com as variadas normas

existentes e que funcionam como ferramentas para a criação das páginas

constituintes de um sítio web e, levado por este interesse no tema, gradualmente

fui aprofundando o meu conhecimento das suas naturezas, estruturas e evoluções.

Tendo como objectivo expôr essas tecnologias, actuais e futuras, o produto final

encontrado neste relatório é o resultado da já referida experiência profissional e

de aturada investigação e consulta, na tentativa de indicar a melhor forma de usar

as tecnologias actuais para que se possa esperar o futuro com segurança e de

previsão de quais as normas que serão reinantes num futuro próximo.



2. Normas Web

Quando o criador da World Wide Web, Tim Berners-Lee, a projectou, o seu

sonho era torná-la um espaço comum de informação onde esta pudesse ser

trocada. A universalidade da web era essencial para esta ideia. Podermos, através

da web, apontar para qualquer recurso, fosse ele pessoal, local ou global. Uma

segunda parte desse sonho era tornar a web num espelho realista das formas

como trabalhamos, jogamos ou socializamos. A cada passo que damos, vamos

tornando este sonho uma realidade.

Mas, neste período de intenso crescimento, a web necessita de orientação por

forma a poder exprimir todo o potencial. As normas web são essas linhas de

orientação, o fio condutor pelo qual todo o desenvolvimento web se deve orientar.

Estas normas ajudam a que todos possamos aceder à informação disponível e,

simultaneamente, a tornar a produção web mais rápida e satisfatória.

A conformidade com as normas torna mais fácil o acesso a pessoas com

necessidades especiais. Estas pessoas, que não devem ver o seu direito de acesso à

informação negado, podem utilizar um navegador que sintetize vocalmente o

conteúdo dos documentos web. Pessoas com dificuldades visuais podem ter

necessidade de alterar a apresentação, ou mesmo aumentar o tamanho do seu

conteúdo, para facilitar a sua leitura. E pessoas com dispositivos móveis deverão

poder navegar pela web com a exacta mesma facilidade que aqueles que possuam

computadores topo de gama.



Existem várias razões para todos aqueles que desenvolvem o seu trabalho para a

web se preocupem com as normas web. Os motores de busca conseguem mais

facilmente indexar sítios, por exemplo. O uso de código que apenas determinado

navegador ou dispositivo consegue perceber, sendo mal interpretado ou ignorado

por outros navegadores ou dispositivos, obriga muitas vezes ao dobro do trabalho

no processo de criação e manutenção de páginas web.

Algumas pessoas poderão achar as normas limitativas. Muito pelo contrário, o

seu uso correcto elimina uma grande parte do trabalho entediante de replicar

código para cada dispositivo, permitindo aos criadores de páginas focarem o seu

tempo e atenção noutras questões mais importantes.

2.1. Como funcionam as normas web

Embora existam normas que se aplicam a todos os aspectos da Internet, como o

ECMAScript, o DOM ou o XML, bem como para regular os user agents, como

também são conhecidos os dispositivos de acesso, e as linhas de orientação de

acessibilidade, quando falamos em normas web, o usual é estarmos a referir-nos

às normas que regulam as tecnologias HTML e CSS. Ambas são formas de

codificação para a criação de uma página web. As normas web existentes para

estas tecnologias funcionam, então, como um livro de regras gramaticais que

descrevem a forma de as implementar.

As normas web não só dizem aos criadores de conteúdo para a web como

codificar os seus documentos, como indicam os dispositivos de acesso a

interpretar e mostrar a informação, por forma a que o utilizador fina l possa

visualizar correctamente o seu conteúdo.



2.2. Porquê separar conteúdo de apresentação

No caso da combinação usual de HTML com CSS, o HTML indica a um

dispositivo de acesso como interpretar o significado das várias partes do

documento, como parágrafos, listas ou imagens, ou seja, a perceber a estrutura do

seu conteúdo. O CSS, por sua vez, indica ao dispositivo a forma como o

documento deve ser apresentado, definindo, entre outras coisas, as fontes e as

cores. Neste caso, estamos a falar da apresentação do documento.

Esta separação de deveres entre HTML e CSS é cada vez mais encorajada pelas

recentes normas publicadas.

A forma tradicional de codificar páginas web tornava o código que definia o

aspecto, parte do HTML. Cada etiqueta, ou tag, HTML possuía informação sobre

a forma como seria apresentada. Por exemplo, considerando uma determinada

empresa que possuía um sítio e que, a determinada altura, decidia mudar por

completo as suas cores oficiais e essa mudança tivesse que se reflectir no seu sítio

web, alguém teria que percorrer cada linha de cada documento que fizesse parte

do sítio e mudar cada referência às antigas cores da empresa. Não será difícil de

perceber que esta não é a forma mais eficiente de produzir e manter páginas web.

Quando a informação relativa à apresentação se encontra separada do conteúdo

da página, torna-se possível alterar qualquer pormenor do layout de uma página,

ou mesmo do sítio inteiro, fazendo apenas modificações menores nas folhas de

estilo descritas nos documentos CSS. Esta possibilidade de, facilmente, se alterar

o aspecto de um sítio inteiro é uma das características que faz o conceito de

separação entre conteúdo e apresentação ser tão poderoso.



2.3. Como saber se um sítio está em conformidade

Estar em conformidade com as normas web significa que o sítio está construído

de acordo com as normas web relevantes publicadas. Existem aplicações que

permitem testar a conformidade de uma página. Estas funcionam um pouco como

um corrector ortográfico, detectando violações às regras estabelecidas pela norma

que é suposto ser cumprida.

2.4. O que significa não estar em conformidade

Nem todos os sítios estão em conformidade com as normas. Alguns dispositivos

de acesso mostraram o conteúdo das páginas de uma forma ligeiramente diferente

do pretendido e definido pelas normas. Dependendo do dispositivo, a diferença

entre o que é pretendido e o que realmente é mostrado pode variar entre não

haver alterações visíveis e haver alterações tais que impeçam completamente a

sua visualização.

2.5. Fuga à conformidade e mitos associdados

Várias razões podem ser apontadas para que um grande de número de sítios não

se encontre em conformidade com as normas. Normalmente esse caso ocorre

quando os criadores de páginas web:

§ Criam páginas com erros, normalmente não intencionais;

§ Não conhecem as normas que lhes permitam escrever páginas em

conformidade;



§ Utilizam ferramentas de geração automática de código que não cumpre as

normas;

§ Utilizam código que tira partido de algumas características específicas que

existem apenas num determinado dispositivo.

Vamos analisar os mitos mais comuns que se opõem à utilização de boas práticas

de codificação através dos standards web.

2.5.1. Mito nº 1: Páginas em conformidade pouco atraentes

O uso de normas não afecta necessariamente o aspecto de um sítio web. Embora

sempre redutora, uma comparação pode ser feita e utilizada para desmontar esta

falsa ideia. Se considerarmos a construção de um qualquer edifício, não podemos

afirmar que as normas que especificam a composição do betão tornem o edifício

feio e aborrecido. Na verdade, as especificações para a composição do betão,

outros materiais e técnicas de construção, desde que cumpridas, tornam possível

confiar na construção do edifício e garantir que será robusto e seguro. Após a sua

construção sólida, nada impede que seja decorado externa e internamente para

que o seu aspecto seja mais agradável.

Se um edifício for bem projectado e adequado aos seus fins, este conseguirá atrair

eventuais compradores, independentemente do tipo de betão utilizado. No

entanto, se a preparação dos materiais de construção não tiver sido feita de

acordo com as especificações e regras existentes, o edifício corre o risco de sofrer

de instabilidade devido à sua má construção.

O mesmo cenário pode ser aplicado às normas web. O seu cumprimento não

impede o bom funcionamento nem a existência de um aspecto agradável. Estar

em conformidade com as normas fornece a um sítio robustez. Se um sítio tem um



aspecto desagradável, a culpa não está nas normas, mas sim em erro s de projecto

e implementação.

2.5.2. Mito nº 2: As normas aumentam o tempo de

desenvolvimento

Os criadores de sítios web que não estejam habituados a produzir código

normalizado, poderão precisar de algum tempo de habituação para se adaptarem a

novos hábitos e paradigmas. Na verdade, dependendo da capacidade e nível

técnico dos criadores, o uso de código normalizado, poderá diminuir de forma

radical o tempo de desenvolvimento. Desde que exista algum domínio sobre a

tecnologia em utilização, excelentes resultados poderão ser obtidos com um

menor custo de tempo. Tomemos em conta os seguintes pontos que descrevem

situações que permitem perceber que tempo pode ser poupado com a utilização de

normas:

§ Apenas uma versão do sítio necessita de ser produzido. Através da

manipulação de folhas de estilo e bom uso das normas web, deixarão de ser

necessários templates especializados para versões de impressão ou de

existir código que detecte o dispositivo que usamos por forma a ramificar

código;

§ É possível configurar ferramentas de produção web como o Dreamweaver

da Macromedia ou o Frontpage da Microsoft. Um investimento inicial em

tempo é necessário para adaptar estas ferramentas a construir código

normalizado para os documentos web que produzem;

§ Facilmente se compreende que um código normalizado, sem o uso de

especificações que apenas funcionam na tecnologia X ou Y, seja mais

facilmente pesquisado em busca de precisão e correcção, pois existem

ferramentas que o fazem de forma automatizada;



§ Quando um novo elemento chega a uma equipa de produção web, este terá

a sua integração no trabalho já desenvolvido facilitada se este estiver em

conformidade com as normas, pois é um código mais claro e consistente.

2.5.3. Mito nº 3: Todos os visitantes utilizam o Internet Explorer

Embora o Internet Explorer da Microsoft seja o navegador mais utilizado hoje

em dia, pode não o ser no futuro. No fim do mês de Maio de 2003, a Microsoft

anunciou que tinha terminado o desenvolvimento das versões gratuitas e

autónomas do seu navegador Internet Explorer que, na verdade, não sofria

alterações significativas desde o já longínquo ano de 2001.

Em Julho de 2003, a Mozilla Foundation foi formada para facilitar o

desenvolvimento do seu navegador open source ao mesmo tempo que o

navegador Netscape via o seu desenvolvimento também extinguido pela AOL, a

empresa que havia comprado a Netscape.

Além do navegador criado pela Microsoft, muitos outros existem no mercado

ocupando o seu espaço que, ainda que menor, não deixam de ser extremamente

relevantes. Mesmo para a plataforma Windows da Microsoft, que domina

esmagadoramente o mercado de desktops, existem as alternativas da Mozilla

Foundation como o navegador incluído no Mozilla Suite, o Mozilla Browser, cuja

base é utilizada para o lançamento dos navegadores com a marca Netscape, e o

novíssimo e revolucionário Mozilla Firefox.

A plataforma Linux que, passo a passo, caminha para ocupar uma porção cada vez

mais significativa do mercado de desktops, não possui o Internet Explorer da

Microsoft. Como tal, depende dos navegadores da Mozilla Foundation ou de

outros como o Opera, que possui versões livres e comerciais, ou o Konqueror.



Não podemos esquecer a plataforma Macintosh da Apple que, apesar de possuir

uma versão ainda menos actual do Internet Explorer produzido pela Microsoft,

conta também com o navegador nativo de nome Safari, bem como os navegadores

existentes para outras plataformas da Mozilla Foundation, a que acresce o criado

especificamente para a plataforma Mac, o navegador Camino.

Como é fácil de perceber, a generalização de que todos os utilizadores usam o

mesmo browser é, como ocorre com a esmagadora maioria das generalizações,

errada. Cabe ao utilizador final a liberdade de escolher o seu dispositivo de acesso

que pretendem utilizar. Como tal, é essencial dotar os sítios de flexibilidade que

só a utilização de código em conformidade com as normas pode trazer.

Para além dos navegadores escolhidos pelo utilizador para visitar um sítio,

existem outros visitantes que poderão não ser esperados. Os motores de busca

dispõem, normalmente, de programas que visitam os sítios web de forma

automática e acedem ao texto que está contido nas páginas. Estes programas,

chamados de spiders, bots ou crawlers, pesquisam o conteúdo dos documentos

web por forma a actualizar as bases de dados dos motores de busca que os

lançaram. Se o conteúdo das páginas não estiver bem escrito e acessível, o motor

de busca pode ser impossibilitado de indexar as páginas.

Como exemplo dos perigos da generalização de que todos os utilizadores usam o

Internet Explorer, tomemos o seguinte cenário em consideração:

§ Toda a empresa utiliza, por norma, o Internet Explorer

§ O acesso à intranet é feito via web e utilizando tecnologias proprietárias e

específicas do Internet Explorer.

§ Ao longo do tempo, a intranet cresce exponencialmente em conteúdo,

através da constante adição de documentos, pessoal e departamentos.



§ Após alguns anos, por razões de segurança e de forma acertada, a empresa

decide adoptar um navegador da Mozilla Foundation, que são navegadores

com respeito pelas normas.

§ Os tempos seguintes são passados a reescrever código para tornar a

intranet acessível de novo a todos os utilizadores.

Muito do trabalho de reescrita podia ter sido poupado se a supracitada intranet

tivesse sido planeada, projectada e implementada com o respeito às normas web

em mente. As normas web foram precisamente projectadas para funcionar em

todos os navegadores e dispositivos de acesso.

2.5.4. Mito nº 4: Não é possível criar páginas iguais em todos os

browsers

Na verdade, a afirmação acima não está de todo errada. Aliás, é uma afirmação

correcta na grande maioria dos casos. O mito reside na ideia de que um sítio deve

ter a exacta mesma aparência onde quer que seja consultado.

Esta ideia deriva, essencialmente, da formação tradicional que os web designers

possuem e do seu hábito de criar layouts para meios de tamanho fixo e

determinado, como a página de um livro, um cartão de boas festas, ou um poster

promocional. É preciso que os criadores de páginas web, nomeadamente os web

designers, interiorizem a ideia de que não estão a criar conteúdo para um meio de

dimensões estabelecidas à partida, mas sim para um meio em que é literamente

impossível prever quem e em que condições esse conteúdo vai ser acedido.



3. World Wide Web Consortium

3.1. Acerca do World Wide Web Consortium

O World Wide Web Consortium (W3C) foi criado em Outubro de 1994 com o

objectivo primordial de potenciar ao máximo a World Wide Web, desenvolvendo

protocolos que promovessem a sua evolução e garantissem a sua

interoperabilidade. A busca pelo cumprimento destes dois objectivos é uma das

forças motoras da organização.

No que concerne à evolução da World Wide Web, existem duas ideias a realçar.

A primeira é que, sem dúvida, é necessária uma busca constante pelo

melhoramento do meio web, minimizando ou eliminando as suas, potenciando as

suas qualidades e, quiçá, descobrindo novas funcionalidades que possam suprir

lacunas que o dia de amanhã torne visíveis. A segunda ideia a realçar é que, ao

falarmos em evolução e futuro, não podemos esquecer o que deixamos para trás.

Um documento web criado hoje, deve continuar a poder ser consultado facilmente

daqui a 5 ou 10 anos.

No que diz respeito à interoperabilidade, o objectivo é de garantir o seu acesso a

uma multiplicidade de dispositivos. Um documento web não deve estar

restringido a apenas poder ser visualizado num navegador. A cada dia que passa,

novos dispositivos que podem ser utilizados para consultar o mesmo conteúdo

vão sendo criados. Actualmente, a mesma página pode ser visualizada através de

navegadores, que já entre si variam significativamente, PDAs, telemóveis, etc.



3.2. Fundação do W3C

A fundação do World Wide Web Consortium em 1994, deve-se a Tim Berners-

Lee, o inventor da World Wide Web, que o fundou o no Laboratory for

Computer Science do Massachussetts Institute of Technology, em colaboração

com o CERN (Centre Européen de Recherche Nucléaire), com o apoio do

DARPA (Defense Advanced Research Project Agency) e da Comissão Europeia.

3.3. Missão do W3C

Promovendo a interoperabilidade e encorajando uma discussão aberta, o W3C

está empenhado em liderar a evolução tecnológica da web. Em cerca de sete anos,

o W3C já desenvolveu para a infraestructura da web mais de cinquenta

especificações técnicas, entre as quais se destacam, por exemplo, as conhecidas

normas HTML 4.01 e CSS1. Assim, e atendendo à referida evolução e à tendência

para a convergência entre os computadores, tecnologias de telecomunicação e

tecnologias multimédia, o W3C tenta corresponder às crescentes expectactivas

dos utilizadores abrindo caminho e traçando um rumo que tem como destino

tornar a web mais robusta, escalonável e uma infraestructura adaptável para um

mundo de informação.



3.4. Objectivos do W3C

Os objectivos a longo prazo do W3C são:

3.4.1. Acesso Unive rsal

Tornar a web acessível a todos, promovendo tecnologias que têm presente as

diferenças existents a nível de cultura, linguística, educação, habilidade, recursos,

dispositivos de acesso e limitações físicas de utilizadores de todo o mundo.

3.4.2. Web Semântica

Desenvolver um ambiente que permita a cada utilizador fazer o melhor uso dos

recursos disponíveis na web;

3.4.3. Web de Confiança

Guiar o desenvolvimento da web com especial e cuidada atenção dedicacada às

novas questões legais, comerciais e sociais levantadas pelo advento desta nova

tecnologia

3.5. O Papel do W3C

Tal como muitas outras tecnologias da informação, particularmente aquelas que

devem o seu sucesso ao crescimento da Internet, a web necessita de evoluir a um

ritmo superior ao de outras indústrias.



O tempo necessário tornar uma ideia num producto ou serviço e disponibilizá-lo

para o mundo inteiro através da web é diminuto. Para muitas aplicações, aliás, os

processos de desenvolvimento e distribuição tornaram-me virtualmente

indistinguíveis. Simultaneamente, é possível proceder a um contínuo

melhoramento do producto devido à facilidade com que um utilizador/cliente

pode fornecer feedback.

Com um universo composto de milhões de pessoas a aplicar as especificações do

W3C e a fornecer o devido feedback, a organização concentra os seus esforços em

três tarefas primordiais:

3.5.1. Visão

o W3C promove e desenvolve a sua própria visão do futuro da World Wide Web.

Contribuições de numerosos investigadores e engenheiros dedicados, trabalhando

nas organizações membro do consórcio, da equipa W3C liderada por Tim

Berners-Lee, e da enorme comunidade web, ajudam o W3C a identificar quais os

requisitos técnicos que devem ser cumpridos para que a web seja

verdadeiramente um espaço universal de informação.

3.5.2. Design

o W3C projecta as normas para que possam cumprir a sua visão, tendo sempre

em consideração as tecnologias existentes bem como as que virão no futuro

3.5.3. Normalização

o W3C contribui para o esforço de normalização das tecnologias web, produzindo

especificações, as Recomendações do W3C, que descrevem aqueles que são os



blocos constructores da web. Estas Recomendações estão livremente disponíveis

para todos

3.6. Princípio de Design da Web

A web é uma aplicação que funciona sobre a Internet e , como tal, herdou os seus

princípios de design fundamentais.

3.6.1. Interoperabildade

As especificações para as linguagens e protocolos utilizadas na web devem ser

compatíveis entre si para que permitam que qualquer hardware e software seja

usado para trabalhar em conjunto.

3.6.2. Evolução

A web deve poder acomodar as tecnologias futuras. Princípios de design como

simplicidade, modularidade e expansibilidade irão aumentar as hipóteses da web

poder ser acedida através das tecnologias emergentes como os dispositivos

móveis e as televisões digitais, assim como outras tecnologias vindouras.

3.6.3. Descentralização

A descentralização é, sem dúvida, a mais recente e mais difícil princípio a aplicar.

Para disponibilizar a web a nível mundial e, simultaneamente, resisitir a erros e

avarias, a arquitectura, tal como a Internet, deve limitar ou mesmo eliminar as

depências de registos centralizados.



Estes princípios servem de guia para o trabalho desenvolvido nas Actividades do

W3C.

3.7. Actividades do W3C

O W3C desenvolve a maior parte do seu trabalho após uma ordem explícita dos

seus Membros. Por norma, os Membros analisam as propostas de trabalho,

formalmente chamadas de Propostas de Actividade. Quando os Membros atingim

um consenso no sentido de continuar esse trabalho, o W3C inicia uma nova

Actividade.

As Actividades do W3C são geralmente organizadas em grupos: Grupos de

Trabalho para desenvolvimente técnico, Grupos de Interesse para trabalho mais

geral e Grupos de Coordenação que gerem a comunicação entre os dois grupos

anteriores.

Estes grupos, formados por representantes das organizações Membro, da própria

Equipa W3C e por alguns peritos convidados, produzem a grande parte dos

resultados da actividade da organização: relatório técnicos, software open source

e serviços. Os grupos asseguram também a coordenação com out ras organizações

criadoras e reguladoras de normas e com comunidades técnicas. Ao todo, existem

mais de trinta Grupos de Trabalho.

Para facilitar a gestão de todos estes processos, a Equipa W3C organiza o seu

trabalho, no qual se destacam as Actividades do W3C, em quatro domínios:

§ Domínio da arquitectura, que desenvolve as estruturas de base para as

tecnologias web;



§ Domínio da Interacção, que busca melhorar a interacção do utilizador final

com a web, e facilitar a existência de um único processo de criação de

conteúdos. Também integra os trabalhos que visam criar formatos e

linguagens de maior precisão, beleza e nível de controlo para os

utilizadores;

§ Domínio da Tecnologia e Sociedade, que visa o desenvolvimento de uma

infraestrutura para a web que possa responder às questões sociais, legais e

de política social;

§ Iniciativa para a Acessibilidade da Web, que integra o compromisso do

W3C de levar a web ao seu máximo potencial, promovendo um alto grau

de usabilidade para pessoas com deficiências. A Iniciativa para a

Acessibilidade da Web, procura dotar a web de acessibilidade através de

cinco área de trabalho principais: tecnologia, linhas de orientação,

ferramentas, educação e investigação e desenvolvimento.

Existem ainda a Actividade de Garantia de Qualidade e a Política de Patentes,

que se aplicam a cada uma ds quatro domínios anteriores.

3.8. Algumas Recomendações do W3C

Guiado pelos princípios de design já referidos, o W3C já publicou dezenas de

Recomendações desde a sua criação. Cada nova Recomendação é simultaneamente

baseada nas anteriores e projectada para que possa ser integrada com novas

especificações. O W3C está a transformar a arquitectura inicial da web,

essencialmente HTML, URIs e HTTP, numa arquitectura que possa servir a web

de amanhã, alicerçada nas fundações sólidas fornecidas pelo XML.



Figura 1 - Arquitectura web para o futuro

As recomendações do W3C incluêm:

3.8.1. (X)HTML

Várias versões já foram publicadas daquela que foi a primeira norma de markup

para a web. A versão 3.2 do HTML foi publicada em Janeiro de 1997, a que

seguiu a publicação do HTML 4, inicialmente em Dezembro de 1997, revisto em

Abril de 1998 e de novo revisto em Dezembro de 1999, já sob a designação de

HTML 4.01. O XHTML 1.0, que utiliza as regras semânticas do HTML 4.01

com a sintaxe do XML, tornou-se uma Recomendação do W3C em Janeiro de

2000. O XHTML 1.1, a versão modularizada do XHTML, foi publicado em Maio

de 2001. Esta modularização do XHTML tornou possível a criação de vários



perfis de XHTML, bem adaptados a dispositivos ou comunidades específicas. O

XHTML Basic, publicado em Dezembro de 2000, é um exemplo de um perfil de

XHTML desenvolvido para os clientes web de telemóveis, PDAs e pagers.

3.8.2. CSS

Duas versões de CSS dão aos designers de sítios web enormes possibilidades para

estilizar as páginas ou documentos web. Possibilitando a separação entre

estrutura e apresentação, as folhas de estilo tornam a gestão de um sítio

extraordinariamente mais simples e ajudam a promover a acessibilidade na web.

O CSS1 foi publicado em Dezembro de 1996 e a versão 2 em Maio de 1998.

3.8.3. XForms 1.0

Criada para ser um substituto para os tradicionais formulários existentes no

HTML, a norma XForms permite aos criadores de formulários fazer a distinção

entre descrição e objectivo dos formulários. A apresentação do formulário, bem

como a forma como os resultados serão apresentados, estão escritas em XML.

Desta forma, a norma Xforms permite fazer uma separação clara entre

apresentação e conteúdo, característica essa que traz grandes vantagens em

termos de reutilização, independência de dispositivos e acessibilidade. Na maior

parte dos casos, os autores podem desenvolver formulários sofisticados sem ter a

necessidade de utilizar programação quer a nível de cliente, quer a nível de

servidor.

3.8.4. XML

A recomendação XML 1.0, publicada em Fevereiro de 1998, foi o primeiro passo

em direcção a uma nova geração da web, permitindo a cada comunidade projectar



linguagens que servissem as suas necessidades particulares e as integrassem

harmoniosamente numa infraestrutura geral baseada em XML.

Desde a versão 1.0, várias Recomendações foram adicionadas à infraestrutura

XML. A norma XML Namespaces foi publicada em Janeiro de 1999 e o

documento “Associando Folhas de Estilo a documentos XML” foi publicado em

Junho de 1999. A norma XSLT, que permite realizar transformações em

documentos XML, em conjunto com a tecnologia XPath, foi publicada em 1999.

Utilizando estas tecnologias, um ficheiro XML pode ser transformado num

qualquer outro tipo de ficheiro XML, como o XHTML ou o SVG, por exemplo.

As tecnologias XLink e XML Base, publicadas em Junho de 2001, definem um

vocabulário geral para hiperligações.

Um grande passo em frente na evolução do XML foi dado aquando da publicação

da norma XML Schema em Maio de 2001. Os XML Schemas são essenciais na

construção de aplicações XML complexas, extendendo enormemente as

funcionalidades já existentes nos DTDs tradicionais.

Uma nova versão, XML 1.1, foi publicada em Fevereiro de 2004.

3.8.5. DOM

O Document Object Model é um interface de programação de aplicações dando

acesso a, entre outras coisas, estrutura, estilo e eventos de um documento.Visto

não depender de nenhuma linguagem de programação em particular, facilita a

construção de páginas e fornece um interface normalizado para outro software

poder manipular ficheiros HTML e XML. O DOM Level 1 foi publicado em

Outubro de 1998, a que se seguiu a publicação do DOM Level 2 em Novembro de

2000 e, posteriormente, do DOM Level 3, mais recentemente, em Abril de 2004.

3.8.6. MathML 2.0

A norma MathML 2.0, publicada em Fevereiro de 2001, cujo trabalho foi baseado

numa outra publicacção anterior de Julho de 1999, é uma ferramenta fundamental

para a produção de conteúdos matemáticos para a web utilizando XML.



3.8.7. PNG

A norma Portable Network Graphics é um formato de imagem do tipo mapa de

bits que permite uma compressão simultaneamente alta e sem perdas. Desde a sua

publicação em 1996, tornou-se um dos formatos de imagem raster mais utilizados

na web. É, actualmente, suportado pelos navegadores mais importantes, embora

de forma muito imperfeita pelo Internet Explorer da Microsoft.

3.8.8. SVG 1.0

A norma Scalable Vector Graphics 1.0 foi publicada em Setembro de 2001. O

SVG é um grande avanço na intenção de dotar a web de gráficos vectoriais.

Baseado no XML e, como tal, editável por qualquer editor de texto e facilmente

reconhecido por motores de busca, o SVG dota a web de conteúdos gráficos ricos,

surgindo como forte alternativa ao uso de imagens do tipo mapa de bits. Versões

posteriores do SVG, como as versões 1.1, Basic e Tiny, estão vocacionadas para o

uso em dispositivos mais pequenos como PDAs e telemóveis.

3.8.9. SMIL 2.0

A norma SMIL 2.0 permite a criação de apresentações multimédia sincronizadas

para a web. O SMIL 2.0 também terá um papel determinante na nova geração de

telemóveis com acesso à Internet. A sua publicação data de Agosto de 2001, tendo

sido baseada numa anterior versão publicada em Junho de 1998.


A Web Semântica fornece uma framework comum permitindo aos dados serem

partilhados e reutilizados ultrapassando as restritivas fronteiras de aplicações,

empresas e comunidades. É um esforço conjunto, liderado pelo W3C, com a



participação de um grande número de investigadores e parceiros industrais. A sua

base encontra-se na Resource Description Framework, RDF, que integra uma

varidade de aplicaçóes que utilizam o XML para sintaxe e URIs para

nomenclatura e ainda a Web Ontology Language, OWL, que fornece um a base

para a criação de ontologias através da utilização da RDF.

Uma primeira versão da norma RDF foi publicada em 1999. A mais recente

versão foi publicada, tal como a OWL, em Fevereiro de 2004

3.8.11. XML-Signature e XML Encryption

Foram publicadas em Fevereiro e Dezembro de 2002 respectivamente, e são

passos importantes em direcção de uma web de confiança. Juntas definem uma

framework baseada em XML que permite a adição de assinaturas digitais e

encriptação de recursos da web.

3.8.12. P3P 1.0

A Platform for Privacy Preferences 1.0, P3P, publicada em Abril de 2002, fornece

uma forma simples e automatizada de dar aos utilizadores o controlo sobre a

informação pessoal nos sítios que visitam.

3.8.13. Voice Framework

O W3C está presentemente a definir um conjunto de linguagens de markup que

abranjam as áreas de diálogo, síntese de voz, reconhecimento de voz, controlo de

chamadas e vários outros aspectos relativos a aplicações interactivas de resposta

de voz.

Como parte integrante deste contínuo desenvolvimento, o W3C já publicou, em

Março de 2004, a norma Speech Recognition Grammar Specification, SRGS, e a

norma VoiceXML.



3.8.14. Linhas de Orientação para a Acessibilidade na Web

A Iniciativa para a Acessibilidade na Web já publiciou duas Recomendações W3C

até agora, para promover o acesso à web a pessoas portadoras de deficiência. Os

princípios nos quais se baseiam estas linhas de orientação também beneficiam

todos os utilizadores e são similares às linhas de orientação utilizadas para o

acesso a partir de dispositivos móveis. A Web Content Accessibility Guidelines

1.0, que explana a forma de criar páginas e sítios web acessíveis, foi publicada em

Maio de 1999. A Authoring Tool Accessibility Guidelines 1.0, que mostra como

construir ferramentas de produção de código que produzam conteúdo acessível a

todos os utilizadores portadores de deficiência, foi publicada em Fevereiro de

2000.

3.9. Desafios para o futuro

Em outras especificações, o W3C procura responder aos desafios colocados

quando consideramos uma Web para o futuro.

3.9.1. Assegurar o acesso à web através de vários dispositivos

A web está a tornar-se acessível através de uma miríade de dispositivos, nos quais

se incluem telemóveis, televisões, câmaras digitais e computadores instalados em

automóveis. A interacção com os recursos disponibilizados pela web pode ser

conseguida através de um teclado, rato, voz, stylus e outros dispositivos de

entrada.

Existe o perigo de apenas algumas partes da web serem acessíveis a partir desses

dispositivos. O W3C dedica-se a assegurar que o universo web não esteja

fragmentado. A organização iniciou recentemente duas Actividades de nome



Independência de Dispositivos e Interação Multimodal, iniciadas em 2001 e em

2002 respectivamente, por forma a contribuir para o grande objectivo W3C de

possibilitar à web um acesso universal.

Estas Actividades continuam e complementam o trabalho já iniciado pela

modularização das normas XHTML e SMIL, pelo advento da norma XSLT,

pelas Linhas de Orientação da Acessibilidade na Web, etc. Todas estas

contribuem para o esforço conjunto de assegurar acesso igual ao mesmo espaço

de informação.

3.9.2. Promover as melhores prácticas

O W3C não pode assegurar a implementação das suas especificações se as

comunidades de produtores/autores e de utilizadores não se convencerem do

valor delas. A promoção e a educação são vitais para o sucesso do W3C.

Parte deste esforço inclui a publicação das linhas de orientação de boas práticas,

incluindo as já disponíveis Linhas de Orientação para Acessibilidade, oferecendo

serviços de validação, desenvolvidos pelo W3C ou pelos seus parceiros, conjuntos

de testes, protótipos e aplicações exemplo e resposta rápida ao feedback e

questões do público.

O trabalho do W3C não acaba quando uma Recomendação é publicada. Ao invés,

continua através da sua promoção, apoio, manutenção e melhoramento das suas

especificações.



3.9.3. Coordenação com as organizações internacionais de

regulação

A integraçao da web na vida quotidiana das pessoas requer a coordenação com os

regulamentos já existentes, bem como aqueles ainda em desenvolvimento, como

as que se referem à protecção de informação.

A manutenção do diálogo entre aqueles que desenvolvem o seu trabalho para a

web e os legisladores é necessária para assegurar um ambiente regulador que

seja justo, preciso e realista.

3.9.4. Atenção à diversidade cultural

De forma a garantir o acesso à web a pessoas de diferentes línguas, diferentes

convenções de escrita e diferentes culturas, o W3C continua o seu importante

trabalho na Actividade de Internacionalização.

3.9.5. Encorajar a investigação

A web deve uma parte do seu rápido crescimento aos avanços permitidos pela

investigação nos últimos trinta anos. Uma continuada evolução ao mesmo ritmo

necessitará de nova investigação nas áreas de represntação de conhecimento,

optimização de protocolos e, de forma geral, no desenho de arquitecturas para

sistemas distribuídos de larga escala.

3.10. A Organização do W3C

Por forma a cumprir os seus objectivos de acesso universal, Web Semântica e

Web de Confiança, enquanto exerce o seu papel de visão, design e normalização e



aplica os seus princípios de design, interoperabilidade, evolução e

descentralização, o W3C organiza-se de acordo com os três seguintes princípios:

3.10.1. Neutralidade

Os componentes da W3C são neutros, tal como a Equipa W3C. O Consórcio

promove a neutralidade encorajando o comentário do público às suas

especificações durante todo o seu ciclo de vida.

3.10.2. Coordenação

A web tornou-se um fenómeno tão importante, quer no seu âmbito, quer no

investimento que suporta, que nenhuma organização a deverá controlar sozinha.

O W3C coordena os seus esforços com outros corpos que regulam normas e

standards e também com outros consórcios como o IETF, Internet Engineering

Task Force, o Unicode Consortium, o Web3D Consortium, e vários comités ISO.

3.10.3. Consenso

O consenso é um dos mais importantes princípios pelos quais o W3C se rege. Na

altura de resolver problemas e de tomar decisões, o W3C procura sempre obter

unanimidade de opinião. No caso de um consenso não ser possível, o W3C

procura decidir considerando as ideias e pontos de vista de todos os participantes

no processo de decisão, incluindo os Membros W3C e peritos convidados, ou

ainda o público em geral.



3.11. Essência do W3C

Resumindo, o World Wide Web Consortium cria normas web. Na sua missão de

potenciar ao máximo a web, desenvolve especificações, linhas de orientação,

software e ferramentas, criando um espaço para para informação, comércio,

inspiração, pensamento independente e compreensão colectiva. No fundo,

podemos condensar a essência do W3C em sete pontos primordiais.

3.11.1. Acesso Universal

O W3C define a web como o universo de informação acessível através de uma

rede, disponível através de um computador, telefone, televisão, ou

electrodoméstico ligado a uma rede. Actualmente este universo beneficia a

sociedade oferecendo novas formas de comunicação interpessoal e oportunidades

de partilha de conhecimento. Um dos principais objectivos do W3C é possibilitar

estes benefícios a todas as pessoas, independentemente do seu hardware,

software, infraestrutura de rede, linguagem nat iva, cultura, localização geográfica

ou capacidades mentais ou físicas. A Actividade de Internacionalização, a

Actividade para a Independência de Dispositivos, a Actividade de Navegação por

Voz, e a Iniciativa para a Acessibilidade na Web demonstram o empenho da

organização em providenciar acesso universal.


Actualmente, as pessoas partilham o seu conhecimento na web em linguagens

perceptíveis a outras pessoas. Na Web Semântica, seremos capazes de nos

exprimirmos de forma que os nossos computadores possam interpretar. Dessa

forma, permitiremos que eles resolvam os problemas que achamos entediantes e

que nos ajudem a rapidamente encontrar a informação que procuramos, seja ela

informação médica, uma análise a um filme, a compra de um livro, etc. As



linguagens semânticas RDF, XML, XML Schema e XML Signatures são os

blocos constructores de uma Web Semântica.

3.11.3. Confiança

A web é um meio de colaboração e não, ao contrário de uma revista, um meio

apenas de leitura. De facto, o primeiro navegador era também um editor, embora

o conceito de navegação a que actualmente as pessoas associam é de que é

primariamente para visualização e não interacção. Na tentativa de promover um

ambiente mais colaborativo, deve ser construída uma Web de Confiança, que

ofereça confidencialidade e confiança, que possa permitir às pessoas serem

responsáveis, e responsabilizadas, pelo que publicam na web. Esses objectivos são

o motor responsável pela maior parte do trabalho do W3C nas XML Signatures,

em mecanismos de anotação, publicação em grupo, controlo de versões, etc.

3.11.4. Interoperabilidade

Há cerca de vinte anos, as pessoas compravam software que apenas funcionava

com outro software do mesmo fabricante. Hoje em dia, as pessoas têm maior

liberdade de escolha e esperam que os componentes de software sejam facilmente

compatíveis com outros. Esperam também poder consultar conteúdo publicado na

web com o seu software preferido, seja ele um navegador típico, um sintetizador

de voz, um navegador Braille, telefone do carro, etc. O W3C, uma organização

neutra a nível de fabricantes, promove a interoperabilidade, projectando e

publicitando linguagens e protocolos não proprietários que evitem a

fragmentação de mercado do passado. Isto é conseguido tentando obter um

consenso da indústria e encorajando um espaço aberto para discussão.



3.11.5. Evolução

O W3C tenciona atingir a excelência técnica, mas está bem ciente que os seus

conhecimentos e necessidades actuais poderão ser insuficientes para solucionar os

problemas de amanhã. Assim sendo, a organização luta para construir uma web

que possa facilmente evoluir para uma web ainda melhor, sem perder o que hoje

funciona. Os princípios de simplicidade, modularidade, compatibilidade e

extensibilidade guiam todos os seus projectos.

3.11.6. Descentralização

A descentralização é um princípio dos sistemas distribuídos modernos, nos quais

podemos incluir as sociedades modernas. Num sistema centralizado, todas as

mensagems ou acções têm que passar por uma autoridade central, causando

engarrafamentos quando o tráfego aumenta. Dessa forma, limitamos o número de

pontos centrais, reduzindo a vulnerabilidade da web como um todo. A

flexibilidade é um parceiro necessário dos sistemas distribuídos, sendo também a

vida e o pulsar de toda a Internet, não só da web.

3.11.7. Melhor multimédia

Todos gostariam de um aumento de interactividade e de conteúdos ricos na web,

incluindo imagens redimensionáveis, som e vídeo de qualidade, efeitos 3D e

animações. O consenso que o W3C procura sempre atingir não é castrador para a

existência de criatividade, nem significa uma navegação menos interessante.

Através dos seus Membros, o W3C escuta atentamente os utilizadores finais e

trabalha em direcção a fornecer uma sólida base de trabalho para o

desenvolvimento de uma web mais atraente e funcional, através de linguagens

como o formato de imagem Scalable Vector Graphics, SVG, ou a linguagem

Synchronized Multimedia Integration Language, SMIL.



4. Normas actuais

4.1. HTML 4.0 - HyperText Markup Language

A norma HyperText Markup Language, HTML, é largamente usada na web

como forma de dotar os documentos web de estrutura. Estes elementos de

estrutura podem ser cabeçalhos, parágrafos, tabelas, acrónimos, entre outros. Os

navegadores interpretam os elementos dos documentos e representam a sua

estrutura de forma perceptível para os utilizadores. Por exemplo, um navegador

gráfico representa tipicamente um elemento de ênfase, contido entre as etiquetas

<EM> e </EM> como texto em itálico, enquanto que um navegador de síntese de

voz pode enfatizar o texto contido nesse elemento através da pronúncia.

Através do uso de folhas de estilo, o autor de um documento HTML pode definir

a forma desses elementos estruturais serem apresentados, alterando a forma como

seriam mostrados por defeito no navegador.

Nesta altura, já não se produzem novas versões da especificação HTML. A versão

4.01 foi a versão final da norma HTML e é agora ultrapassada pela norma

XHTML. A criação de documentos XHTML não é feita de forma

substancialmente diferente de documentos em HTML tradicional, mas permite

tirar grandes vantagens do seu uso, especialmente em aplicações mais complexas.

Visto o XHTML ser uma redefinição do HTML para estar em conformidade com

as regras do XML, o XHTML herda características de ambos. O XHTML pode

então tirar partido do facto do HTML estar largamente adoptado, e herdar o

poder de manipulação de informação do XML.



4.2. XML 1.0 - Extensible Markup Language

A tecnologia Extensible Markup Language (XML) é uma linguagem de markup

como o HTML mas, ao invés de ter um conjunto estabelecido e limitado de

elementos que podem estruturar um documento, é dotado de uma flexibilidade

que permite a criação de conjuntos de elementos estruturais definidos pelo autor

do documento, tornando-o ideal para a organização de grandes quantidades de

dados e utilização em bases de dados e motores de busca. Algumas das aplicações

do XML, como o XHTML e o MathML, já se tornaram Recomendações oficiais

do World Wide Web Consortium. Outra característica do XML é a de, através

do uso de XML namespaces, permitira utilizar vários conjuntos de elementos

estruturais simultaneamente no mesmo documento.

O standard XML funciona como base para um bom número de outras

tecnologias, actuais e emergentes, nas quais se incluem e destacam:

§ XSL, eXtensible Stylesheet Language, é uma família de recomendações

que descreve a forma de apresentar o conteúdo de documentos XML.

Permite executar transformações nos documentos XML e torná-los em

outros formatos derivados como o XHTML, por forma a facilitar a sua

apresentação nos navegadores actuais;

§ RSS, “Really Simple Syndication”, “RDF Site Summary” ou “Rich Site

Summary”, é uma conjunto de formatos populares para a busca e aquisição

de notícias e artigos de sítios web;

§ SVG, Scalable Vector Graphics, e SMIL, Synchronized Multimedia

Integration Language, são normas para gráficos e multimédia. O uso de

animações SVG pode produzir efeitos interessantes, semelhantes a simples

animações construídas com a ferramenta proprietária Flash da

Macromedia, mas com uma melhor estrutura semântica. O SMIL é uma



linguagem que permite combinar áudio, vídeo, imagem e texto para

construir apresentações multimédia;

§ XForms é um método de criação de formulários para a web onde a

funcionalidade e apresentação do formulário se encontram definidas

separadamente. Devido à sua estrutura XML, um formulário em particular

pode ser configurado e transformado para ser apresentado de formas

várias, tal como XHTML.

4.3. XHTML 1.0, 1.1 e Modularização

O standard XHTML 1.0 é uma reformulação do HTML como uma aplicação do

XML. O XHTML 1.0 pode ser ideologicamente descrito como vindo do HTML

4.01, mas com o rigor que lhe é conferido pela influência da sua raíz XML.

O código XHTML é apresentado num navegador de forma idêntica ao código

HTML equivalente. O uso do XHTML, no entanto, pode ser importante se

houver a necessidade de enviar o seu conteúdo para um PDA, pois as regras mais

estritas do XHTML tornam o seu processamento automático mais rápido e

eficaz.

O XHTML 1.0 possui três possíveis tipos de Document Type Definition: Strict,

Transitional e Frameset. Este modelo tripartido surgiu originalmente para ser

aplicado à norma HTML 4.0 e foi transposto para a seguinte versão HTML 4.01.

Algumas das técnicas e regras utilizadas para o XML são também utilizadas no

XHTML:

§ O tipo de documento é declarado através da correcta declaração do

DOCTYPE;



§ A estrutura de um documento para estar em conformidade com as normas

deve conter uma declaração do tipo de documento através do DOCTYPE,

um elemento html com o XHTML namespace declarado, um elemento

HEAD que inclua um elemento TITLE e um elemento BODY;

§ Todos os elementos e respectivos atributos devem estar em minúsculas e

os valores de cada atributo devem estar contidos entre aspas;

§ Todos os elementos não vazios como os elemento P e LI devem ter um

elemento terminador;

§ Todos os elementos vazios, como os elementos BR, HR, IMG devem estar

devidamente terminados através uma barra na própria etiqueta;

§ Os documentos devem poder ser validados de acordo com o DTD que

declaram.

A norma XHTML 1.1 é composta de três partes principais:

§ Um DTD XHTML 1.0 Strict, com ligeiras modificações;

§ Modularização do XHTML;

§ A Anotação Ruby.

Para escrever código XHTML 1.1 pode escolher-se uma de duas maneiras. Um

implica a declaração de um DTD XHTML 1.1 que está publicamente disponível.

Dessa forma, existe a garantia de um trabalho extremamente estruturado pois

não existem elementos apresentacionais na norma XHTML 1.1. A separação de

estrutura e apresentação é completa nesta norma, e toda a apresentação deve ser

representada numa folha de estilo.

Outra forma de escrever documentos XHTML 1.1 é a de utilizar a Modularização

do XHTML. Consite na descretização de elementos familiares de HTML e

XHTML como textos, tabelas ou formulários. É depois possível possível escrever



um DTD costumizado utilizando apenas os componentes necessários. Este

aspecto serve de exemplo de extensibilidade, dando a possibilidade ao criar do

documento de costumizar o seu código.

A Anotação Ruby é um meio especial de lidar com certas notações de caracteres

asiáticos. Este é um trabalho que está incluído na tentativa de internacionalização

da web.

4.4. CSS - Cascading Style Sheets

A tecnologia Cascading Style Sheets, CSS, é um mecanismo de definição da

aparência dos elementos de um documentos web, atribuindo estilo s a tipos de

elementos, classes de elementos definidas pelo utilizador e instâncias individuais

de alguns elementos, deixando a estruturação semântica dos elementos para as

linguagens como o HTML ou XHTML. As folhas de estilo podem ser utilizadas

para definir de forma consistente o aspecto de um sítio inteiro e podem definir os

tipos de fontes, cores e posicionamento dos vários elementos. Esta característica

de unificar o aspecto de um sítio numa folha de estilo, podendo fazer-se alterações

completas que se reflectem no sítio inteiro reescrevendo apenas algumas linhas de

código é o que faz esta tecnologia ser tão valiosa. Além disso, pode também

definir diferentes apresentações para outros tipos de dispositivos, estabelecendo

estilos próprios a determinados elementos apenas entendíveis por esses

dispositivos.

4.5. DOM 1 - Document Object Model Level 1

O DOM permite que o poder e interactividade de uma linguagem como o

ECMAScript, a versão normalizada do JavaScript, possam ser adicionados e

utilizados numa página web. Em termos de programação, o Document Object



Model Level 1 é uma Application Programming Interface, ou API, para a

interacção com as páginas web, permitindo ao ECMAScript um fácil acesso à

estrutura, conteúdo e apresentação de um documento escrito em linguagens como

HTML e CSS.

O Document Object Model é compatível com os futuros desenvolvimentos em

termos tecnológicos. Permitirá a qualquer linguagem a interacção com qualquer

outra linguagem utilizada no documento. Esta norma permite facilmente

dinamizar uma página HTML estática.

4.6. ECMA Standards

4.6.1. O que é o ECMA

O European Computer Manufacturers Association, ECMA, é uma organização

fundada oficialmente em 1961 por forma a ir de encontro às necessidades de

normalização do formatos utilizados em computadores, nomeadamente

linguagens de programação e códigos de input/output . O ECMA está sedeado na

cidade Suiça de Genebra, perto das sedes da International Organization for

Standardization, a conhecida ISO, e do International Electrotechnical

Commission, IEC. Em 1994, o designação oficial da organização passou a aser

ECMA – European Association for Standardizing Information and

Communication Systems, para que pudesse refectir melhor a sua agora mais

abrangente área de actuação.

4.6.2. O que faz

O principal objectivo da organização ECMA é o desenvolvimento de Normas e

Relatórios Técnicos na área das tecnologias da informação e comunicação. Sendo

a ECMA uma associação composta por outras organizações e não sendo um



instituto de normas oficial, muitas vezes colaboram com out ros institutos

nacionais ou internacionais oficiais.

As normas ECMA foram aceites como base para as normas internacionais e

Europeias. Até hoje, mais de duzentas e setenta Normas ECMA e setenta

Relatórios Técnicos foram publicados. Destas normas, oitenta e cinco fora aceites

como normas internacionais pela ISO e vinte e cinco foram aceites como normas

Europeias pelo European Telecommunications Standards Insititute, ETSI.

4.6.3. ECMAScript, o JavaScript normalizado

O ECMAScript é uma linguagem de programação normalizada, baseada

grandemente nas linguagens JavaScript da Netscape e JScript da Microsoft.

O principal uso do ECMAScript, que é uma linguagem orientada a objectos, é o

de manipular os objectos constituíntes uma página web que estão especificados

pelo Document Object Model. Estes objectos, que podem ser os elementos ou a

página inteira em si, podem ser adicionados, removidos, movidos e ter as suas

propriedades alteradas. Isto torna a implementação de efeitos como texto

animado, animações relativas ao movimento do rato ou a validação do input de

um utilizador num formulário antes de haver submissão de dados para o servidor.

De referir que o uso de ECMAScript deve ser limitado ao máximo. Tornar a

navegação dependente do uso de scripts pode levar a graves problemas de

acessibilidade.



5. Benefícios das normas

5.1. Acessibilidade

5.1.1. Para o software

Estar em conformidade com as normas web pode dar uma grande visibilidade a

um sítio através dos motores de busca. A informação estrutural que existe em

documentos normalizados torna mais fácil para os motores de busca o acesso e

avaliação da informação, podendo indexar com mais precisão as páginas.

Com o uso de código normalizado e, consequentemente, com o dispôr de

documentos correctamente estruturados semanticamente, a adição de um motor

de busca interno ao sítio fica também grandemente facilitado e produz melhores

resultados.

As normas estão escritas por forma a que os navegadores antigos consigam

perceber a estrutura básica dos documentos. Ainda que não tenham a capacidade

de interpretar e mostrar correctamente as mais recentes normas, continuam a ser

perfeitamente capazes de disponibilizar o conteúdo do sítio.

Código normalizado dá a oportunidade de utilizar um serviço de validação para

aferir da correcção de uma página. Os validators, como se designa o software que

valida o conteúdo de um documento web, processam o documento e apresentam

os erros gramaticais do nosso documento e tornam o trabalho de detecção e

correcção de falhas mais fácil e menos moroso.



Um documento construído de acordo com as normas pode facilmente ser

convertido para outro formato, como um formato de bases de dados ou

documentos reconhecíveis por processadores de texto. Assim, o uso da

informação constante de um documento web torna-se mais versátil e simplifica o

processo de migração para novos sistemas de hardware ou software.

5.1.2. Para as pessoas

O conceito de Acessibilidade é importantíssimo e é uma ideia com especial relevo

no desenho de muitas normas web, especialmente no HTML.

Acessibilidade significa, não só, dar acesso à web a pessoas portadoras de

deficiência, mas também permitir a que as páginas possam ser interpretadas e

percebidas por pessoas que utilizam dispositivos de acesso diferentes dos

habituais, tais como os navegadores de síntese de voz que lêm o conteúdo dos

documentos para as pessoas com dificuldades visuais, como os navegaores Braille

que traduzem o texto para a linguagem Braille, linguagem de leitura dos

invisuais, ou os dispositivos portáteis como os cada vez mais habituais e evoluídos

terminais móveis cujo espaço de visualização ainda é diminuto, entre outros

dispositivos pouco habituais

A variedade de métodos de acesso aos recursos web aumenta a cada dia e ajustar

ou replicar sítios web inteiros para satisfazer individualmente as necessidades de

cada um tornar-se-á um processo cada vez mais complicado. Seguir as normas é

um enorme passo em direcção à resolução deste problema. Produzir sites em

conformidade com as normas assegura que, não só os navegadores tradicionais,

antigos e modernos, podem apresentar o conteúdo dos sítios de forma correcta,

como também que isso se verifica com os dispositivos de acesso menos comuns.

Ignorar as normas web tem consequências óbvias: a mais imediata delas é que se

restringe o acesso ao sítio. No mundo empresarial, não fará muito sentido ser

descriminatório e limitar ou mesmo impedir o acesso a uma fracção que se poderia

revelvar importante e proveitosa para o negócio. Num sítio de negócios, por



exemplo, negar o acesso a uma pequena porção de potenciais clientes poderá

reflectir-se num impacto enorme a nível de receitas. Num sítio web faz todo o

sentido permitir o acesso a todos, desde pessoas fisicamente aptas ou que possuam

alargados recursos materiais, até às pessoas com recursos mais limitados, sejam

materias ou físicos.

5.2. Estabilidade

A maior parte das normas web estão desenhadas de forma a poderem ser

compatíveis com as normas anteriores e com as que serão adoptadas no futuro, de

forma a que os dados criados de acordo com as normas antigas continuem a

funcionar nos novos navegadores e que os dados criados de acordo com as

normas mais recentes possam ser mostrados com resultados aceitáveis nos

navegadores mais antigos.

Durante o ciclo de vida de um sítio web, este pode vir a ser trabalhado por várias

equipas de designers e programadores diferentes e, por isso, é importante que

essas pessoas possam facilmente compreender o código escrito e editá-lo de forma

fácil. As normas web forncem um conjunto de regras que cada pessoa envolvida

no processo de criação de páginas e sítios web possa seguir, perceber e com o qual

possa tornar-se familiar. Dessa forma, quando um sítio está produzido de forma

normalizada, a transição entre elementos antigos e novos nas equipas de trabalho

é suavizada e facilitada.

5.3. Benefícios para uma empresa Podemos analisar os benefícios maiores da adopção das normas web. A

incorporação desses standards nos projectos web poderá:



§ baixar os custos de desenvolvimento e produção;

§ baixar os custos de manutenção;

§ aumentar o universo de pessoas que podem aceder aos recursos;

§ baixar os custos de alojamento.

Para tirar todo o partido destes benefícios, o uso correcto de normas web deve ser

adoptado como política primordial.

5.3.1. Custos poupados durante do desenvolvimento

No método tradicional e obsoleto de construção de sítios web, o processo de

mudança dos elementos de apresentação, como as fontes, cores e até o layout das

páginas, envolvia a edição de cada umas das páginas que constituiam o sítio para

preceder às alterações o que, de acordo com a dimensão do sítio, poderia totalizar

centenas ou milhares de alterações mínimas. A criação de protótipos e alteração

durante a própria criação do sítio é extremamente facilitada quando o conteúdo e

apresentação estão completamente separados e a adopção da tecnologia CSS para

layout é utilizada.

As normas web foram projectadas também para encorajar a separação de

conteúdo e estilo, para que a alteração dos elementos de um não afecte os

elementos do outro. A alteração do conteúdo de um documento, os gestores de

conteúdo não precisam de modificar a informação relativa à apresentação. Da

mesma forma, os responsáveis pelo aspecto do sítio, não terão que se preocupar

com a informação que descreve o conteúdo das páginas, mas sim apenas alterar

nas folhas de estilo as características de apresentação dos elementos.

Se, a determinada altura da vida de um sítio web, houver a necessidade de alterar

seu aspecto, sejam alterações profundas devido a uma nova imagem da instituição,



organização, empresa ou indivíduo que o sítio representa, sejam alterações

mínimas de refrescamente de estilo para dotar o sítio de um aspecto mais

moderno e actual, o processo de modificação pode ser tão simples como a criação

de uma nova folha de estilo, ou a mera alteração de alguns dos seus elementos, ao

invés do moroso e complexo processo de edição de cada etiqueta HTML de cada

página que constitui o sítio.

Por vezes, é possível cair na tentação de utilizar um CMS, Sistema de Gestão de

Conteúdos, apenas porque se pretende ter um controlo sobre o aspecto de um

sítio web. Este tipo de software, por vezes caro e cujas potencialidade são mal

aproveitadas, deixa de ser necessário quando utilizado apenas como ferramenta de

criação e gestão de modelos ou templates. A simples edição de um ficheiro CSS

permite a completa alteração de todas as páginas de um sítio web.

Um efeito colateral da aplicação das normas a projectos web, é o de o projecto ser

menos dependente dos hábitos de codificação de um só autor. A utilização de

regras normalizadas, concisas e precisas como são as normas web, permitem o

constante desenvolvimento sem problemas de adaptação e eficiência,

independentemente do autor que está a desenvolver o projecto.

5.3.2. Custos poupados durante a manutenção

O código bem escrito e em conformidade com as normas web é conciso, limpo e

claro. Isto representa um grande acréscimo de tempo poupado nos processos de

actualização e alteração de um sítio.

§ Layouts baseados em CSS permitem a facil adição de características as

determinados elementos de uma páginas, ou mesmo a actualização

completa sem necessidade de editar cada página individualmente;



§ A mudança de cores ou fontes pode ser efectuada ao sítio completo de

forma rápida sem necessidade de interferir com o conteúdo;

§ Actualizar o sítio por forma a poder tirar vantagens das novas normas,

visto que as novas normas são sempre projectadas com base nas

anteriorores, é mais simples quando toda a apresentação está concentrada

num só documento de folha de estilo.

5.3.3. Custos poupados no dia a dia

Quando um utilizador acede a um recurso de um sítio web, seja qual for a

quantidade de dados necessários à sua transferência para o cliente, seja um

gigabyte ou um simples bit, este terá sempre o seu custo. Quanto menos dados

forem enviados para o cliente, menor será o custo de alojamento.

§ Custos significativos são poupados devido à simplicidade e clareza das

páginas construídas em conformidade com as normas. Existem estudos

que mostram que o uso de design baseado em CSS, a separação de

conteúdo de apresentação e a produção de código normalizado permite

uma redução do peso de um sítio de 25% a 50%. Esta redução do tamanho

físico dos documentos web permite também que os utilizadores consigam

tempos de carregamento das páginas significativamente menores, o que

leva a uma experiência de navegação mais agradável e proveitosa, se

considerarmos que o tempo é um bem cada vez mais escasso na vida de

cada um;

§ Ao utilizar folhas de estilo em ficheiros CSS que possam ser referenciados

por todas as páginas de um mesmo sítio, é possível evitar transferências de

dados redundantes, visto que as folhas de estilo podem ser guardadas em



memória cache, o que assegura que os dados relativos a esses documentos

são apenas carregados uma vez por utilizador.

Ambos os factores mencionados acima contribuem para que seja possível poupar

largura de banda, o que se traduz num menor custo de manutenção de um sítio

web através apenas do bom uso das tecnologias à disposição de cada criador de

sítios web.

5.3.4. Aumentar a audiência do sítio

Um sítio que cumpra com as normas e linhas de orientação para a acessibilidade e

internacionalização e, como tal, tem a possibilidade de ser acedido por toda a

gente, logo estará em vantagem relativamente aos sítios que não o fazem.

§ Os esforços feitos para que um sítio web cumpra com os standards de

internacionalização terão contrapartidas positivas, permitindo o acesso e

utilização do mesmo a pessoas de todos os lugares. Estes esforços também

significam que uma empresa ou organização que se pretenda expandir num

país de língua diferente, não terá que perder tempo a redesenhar o sítio

inteiro para que funcione na nova língua.

§ Ao assegurar que um sítio cumpre com as linhas de orientação para a

acessibilidade de um sítio web, podem ser evitadas queixas de potenciais

utilizadores prejudicados. Várias leis estão a ser aprovadas no mundo

inteiro para que a acessibilidade na web seja incluída nas leis de direitos

humanos ou nas leis que regulam do direito de acesso à informação.



5.3.5. Melhorar a imagem produz retorno financeiro

A adopção das normas web pode ser um ponto a favor para a imagem de uma

empresa ou instituição. Embora alguns custos financeiros possam ser inevitáveis

no processo de transição, existe um imediato retorno na forma de melhoria de

imagem perante a comunidade. Ao adoptar as normas web, passa-se a imagem

que o autor do sítio:

§ Acredita que a informação deve ser acessível a todos, independentemente

das tecnologias que escolham para a aceder;

§ Recusa descriminar alguém com base na forma e circunstância em que o

acesso é feito e, como tal, se preocupa com a existência de uma boa

experiência de navegação de cada utilizador:

§ Certifica-se que o acesso aos conteúdos do sítio é permitido a uma maior

audiência, assegurando maior visibilidade dos mesmos, potenciando as

possibilidade de negócio.

O uso das normas web não só se afigura como a melhor prática e um bom

exercício de boa cidadania, como abre novas oportunidades de alargar a carteira

de actuais e potenciais clientes.

5.3.6. Estar um passo adiante

Devido ao facto do número de empresas e organizações que estão conscientes da

existência das normas web e, como tal, menos ainda estarem a considerar o seu

impacto nos seus projectos ou terem investido para utilizá-los de facto para seu

benefício, vislumbra-se uma boa oportunidade para se estar um passo à frente e,

consequentemente, em vantagem relativamente à concorrência.



As normas web estão desenhadas para serem extensíveis e facilmente utilizáveis

com um crescimento futuro em mente. As normas web são uma forma de investir

no futuro pois permitem que:

§ Sejam criados projectos web com espaço para crescer;

§ Sejam evitados os riscos e perigos de se ficar atado a tecnologias

proprietárias que podem ter um ciclo de vida limitado;

§ Sejam adoptadas boas práticas de nível técnico e social;

§ Sejam produzidos sítios web acessíveis a todos;

§ Sejam produzidos sítios web cujos conteúdos podem ser acessíveis e

utilizáveis a partir de qualquer dispositivo de acesso.



6. Adopção das normas

6.1. Melhorar o layout de um sítio com o uso das normas

Na web, as normas e o design estão relacionadas, mas podem também ser

bastante independentes um do outro. Um sítio que não esteja em conformidade

com as normas pode passar a estar sem que o design seja afectado. Por outro lado,

o uso de standards web dota um designer de uma flexibilidade de design que lhe

permite a criação de layouts impossíveis de realizar de forma não normalizada.

Método

de Layout Vantagens Desvantagens

Tabelas

· funciona uniformemente na maioria dos navegadores visuais

· é possível ter um layout que respeite as normas do HTML

· na esmagadora maioria dos casos, não se consegue construir um layout que respeite as normas

· não é flexível o suficiente para funcionar em todos os dispositivos de acesso

· o conteúdo pode não ser acessível a todos os utilizadores

CSS

· conteúdo disponível em todos os dispositivos de acesso e plataformas

· ficheiros mais pequenos e tempos de carregamento de páginas mais rápidos

· menor uso de largura de banda

· desenvolvimento e manutenção mais rápidos

· mais fácil de redesenhar

· utilizadores com navegadores mais antigos não poderão gozar da mesma experiência visual pois o CSS não é correctamente interpretado nesses dispositivos

· tempo dispendido na aprendizagem de novas técnicas

Tabela 1 - Métodos de Layout



6.1.1. Layout baseado em tabelas

A forma tradicional de proceder ao design de páginas web é normalmente a que

envolve a criação do layout baseado em tabelas. Utilizando este método, os

elementos constituintes de uma página web, como títulos, menús, imagens e

texto, estão todos colocados dentro de tabelas HTML.

A grande vantagem deste método tradicional consiste no facto de as tabelas já

fazerem parte da norma HTML há muito tempo e, por isso, são bem conhecidas

dos profissionais que desenvolvem o seu trabalho na web e são interpretadas de

forma minimamente correcta e consistente na maior parte dos navegadores

gráficos. Convém referir que, apesar de desaconselhado, é possível obter um

layout baseado em tabelas que esteja em conformidade com as normas menos

recentes.

Uma desvantagem do seu uso advém do da falta de conhecimento das normas por

uma boa parte dos criadores web, tal como da fraca capacidade de as implementar

por parte das ferramentas de produção de código mais utilizadas, o que faz com

que muitos sítios web com este tipo de layout não tenham código normalizado.

Os layouts criados com este método não são suficientemente flexíveis para

poderem funcionar em todos os tipos de dispositivos. As recentes tecnologias sem

fios, bem como tecnologias de assistência a pessoas portadores de deficiência

como os navegadores de síntese de voz, não conseguem interpretar

correctamente as layouts baseados em tabelas.

6.1.2. Layout baseado em CSS

Um método cada vez mais usado para a criação do design de sítios web sem o

recurso a tabelas é o de representar a apresentação do sítio num ou mais ficheiros

globais de folhas de estilo. Isto significa que se pode utilizar HTML ou XHTML



exclusivamente para a criação do código estrutural que identificará o significado

de cada elemento textual, ao invés de indicar também o seu aspecto.

As vantagens do uso de folhas de estilo CSS para a apresentação já foram

discutidas anteriormente no ponto dois do segundo capítulo.

A maior desvantagem do uso de CSS para o layout reside na impossibilidade dos

navegadores mais antigos não conseguires interpretar e apresentar o design na

perfeição, visto que esta era uma norma emergente na altura em que os

navegadores das gerações anteriores foram criados. Através do bom uso das

normas, as páginas continuarão a poder ser consultados nos navegadores mais

antigos, que apenas perderão alguns elementos de apresentação, mantendo

intacto o conteúdo. Os navegadores mais modernos como os da Mozilla

Foundation, Opera, Konqueror ou Safari, não têm qualquer problema na

interpretação de design feito através de CSS, o que já não acontece com o

Internet Explorer da Microsoft que continua a interpretar erradamente, ou a

ignorar, muitas das regras impostas pela norma CSS. Outra desvantagem está na

falta de hábito que os criadores de páginas web têm no uso deste tipo de método.

6.1.3. Exemplo de utilização de tabelas para layout

Nas figuras seguintes podemos observar os riscos do abuso de tabelas para a

definição de layout. Normalmente, a facilidade com que as tabelas permitem

definir o posicionamente dos elementos conduz a um hábito de utilização

desmedida das suas características para resolver toda e qualquer situação. Sem

grandes esforços, podemos encontrar utilizações abusivas das características das

tabelas, quando um correcto uso de CSS poderia levar a um código mais limpo e

leve.

A imagem que se segue mostra uma tabela que aparenta ser perfeitamente

simples e normal.



Figura 2 - Tabela HTML

No entanto, se observarmos na figura seguinte a sua estrutura através uma

ferramenta de edição WYSIWYG, que significa What You See Is What You Get,

podemos observar a complexidade da estrutura que suporta uma tabela que

parecia primar pela simplicidade.

Figura 3 - Estrutura interna de Tabela HTML



Podemos verificar a estrutura altamente complexa e imbricada que foi utilizada

para a sua construção. As tabelas e respectivas divisões em células foram

utilizadas para tudo, desde a aplicação de margens que poderiam ser definidas

facilmente numa linha de código CSS até ao seu uso para a reprentação de listas,

ignorando o facto de existerem elementos HTML precisamente para o mesmo

efeito como o conjunto UL e LI.

6.2. Decidir qual o método a escolher.

Ambos os métodos podem ser utilizados para construir páginas em conformidade

com as normas, mas no processo de escolha de quais as normas e métodos a

utilizar, é necessário decidir qual o método que produz o maior retorno. Mas,

para aproveitar todas as potencialidades de uma web normalizada, é aconselhável

a adopção do método baseado em CSS, visto ser a metodologia que mais se

aproxima das normas que estarão previsivelmente em vigor num futuro próximo

e que mais se aproxima do cumprimento das linhas de orientação para a

acessibilidade.

6.3. Escolhendo as normas

6.3.1. Escolher um método de layout.

Nas linhas acima, foram descritas as duas principais formas de criação de layout

usadas hoje em dia: o método baseado em tabelas, que utiliza as tabelas do HTML

para criar as diferentes áreas de uma página, e o método baseado em CSS, que

utiliza a norma Cascading Style Sheets para a definição do aspecto e

posicionamento de cada elemento de um documento web.



Resumindo, o método baseado em CSS permite a acessibilidade e

interoperabilidade limitando as possibilidades de apresentação nos navegadores

mais antigos, enquanto que o método baseado em tabelas permite a criação de

layouts que funcionem em navegadores antigos, mas é menos flexível e funcional

quando os conteúdos são acedidos por novos dispositivos.

Nas figuras anteriores podemos verificar o que ocorre vezes sem conta.

6.3.2. XHTML ou HTML

Ambos os métodos acima descritos permitem o uso de XHTML 1.0 e CSS

válidos. Como tal, e não existindo vantagens técnicas no uso de HTML 4.01, cada

novo projecto deverá tirar partido das normas mais recentes como o XHTML,

pois, devido à sua modularidade, será possível gerir diferentes versões de

XHTML, como as que se destinam especificamente a dispositivos móveis, com

bastante facilidade.

Pode ser argumentado que não existem reais vantagens no uso da norma

XHTML, pois a maior parte dos navegadores actuais não o interpreta de forma

muito diferente do HTML 4.01. No entanto, não existem grandes mudanças

quando comparadas as formas de escrever HTML e XHTML. Quando todos os

navegadores forem capazes de tratar XHTML de forma correcta, já não será

necessário reescrever código.

6.4. Exigir o melhor

Se o processo de criação do projecto envolver outsourcing, é essencial insistir na

exigência de que as normas web sejam incluídas e integralmente cumpridas.



§ Ter o cuidado de especificar quais as normas essenciais ao projecto e que

devem ser cumpridas, bem como a versão dessas mesmas normas que são

necessárias. Por exemplo, pode querer-se um sítio que esteja construído

segundo as tecnologias XHTML 1.0 Strict, CSS 2.0 and SVG 1.1;

§ A acessibilidade deve ser um requisisto fundamental. O projecto deve

respeitar as linhas de orientação para a acessibilidade a conteúdos web e as

próprias leis locais sobre a acessibilidade;

§ Se o sítio cruzar fronteiras nacionais ou culturais, assegurar que o seu

conteúdo pode chegar a todos. A equipa que produz o sítio deve ter em

conta as normas de internacionalização.

6.5. Educar a equipa de desenvolvimento

Normalmente, a produção de um sítio envolve mais do um elemento. Envolve

toda uma equipa de desenvolvimento. Nesta, e dependendo do nível técnico e de

experiência de cada um, podem ser encontrados elementos com total ou parcial

desconhecimento relativamente às normas web.

Os autores de conteúdos web têm vindo a adoptar muito lentamente as normas

web pelas razões que se seguem:

6.5.1. Nunca foram devidamente ensinados no seu uso

O ritmo de crescimento da web é alucinante e, devido a esse facto, muitos dos

recursos disponíveis para a aprendizagem dos conhecimentos necessários a

desenvolver trabalho no meio web como cursos ou livros, rapidamente ficaram

desactualizados e obsoletos. Isso leva a que quem não está permanentemente

atento e em constante actualização de conhec imentos, rapidamente se vê



ultrapassado e a produzir de acordo com as normas de ontem, quando deveriam

produzir de acordo com as normas de amanhã.

É importante que a equipa responsável pela produção esteja bem informada no

que concerne às normas web pois são estas que asseguram que o sítio está

devidamente preparado para o presente e para o futuro, sem descriminar nem

esquecer aqueles que insistem em permanecer no passado.

Para que as normas possam ser efectivamente implementadas, devem ser

treinados e instruídos nas normas web:

§ A equipa de desenvolvimento, que fará a implementação inicial e que terá a

maior responsabilidade em garantir o funcionamento do sítio de acordo

com as normas existentes;

§ A equipa de design, que deverá estar consciente de todas as

potencialidades de um layout baseado em código normalizado;

§ Os gestores de projecto, que devem conhecer os princípios em que assenta

o trabalho que estão a coordenar;

§ A equipa de manutenção, que deverá saber interpretar o código já

produzido e implementado para que lhe possa dar continuação sem quebra

de normas;

§ A equipa de controlo de qualidade, que deve ser capaz de assegurar o

cumprimento das normas;

§ Os produtores de conteúdo, que devem produzí-lo de acordo com as

normas, para que possa integrar-se facilmente na estrutura já criada.

6.5.2. As ferramentas utilizadas não produzem código standard

Durante a fase de maior crescimento da web, os fabricantes de software não

estavam preocupados em criar sítio web de qualidade. Desde que as ferramentas



produzissem resultados visualmente apelativo no navegador mais utilizado do

mercado, a produção de conteúdo de qualidade não era um requisito necessário ou

sequer considerado. Consequentemente, muitas ferramentas de produção de

código web produzem HTML com base em regras e práticas desactualizadas. Se a

equipa de desenvolvimento não estiver a usar uma ferramenta capaz de produzir

código standard, é inevitável que o resultado seja um sítio que não esteja em

conformidade com as normas.

No entanto, hoje em dia existe uma maior consciencialização para a importância

das normas. Ferramentas profissionais como o GoLive CS, parte do pacote

Creative Studio da Adobe e como a ferramenta Dreamweaver MX, incluída num

pacote semalhante da Macromedia, já são capazes de produzir documentos com

código XHTML e CSS válido. Naturalmente que a ferramenta Frontpage da

Microsoft, seguindo as mesmas linhas de orientação definidas para o Internet

Explorer, continua a ignorar as normas e a produzir código de péssima qualidade.

6.5.3. “É demasiado difícil”

Muitos criadores de conteúdos web aprenderam apenas uma única forma de criar

sítios web e consideram não haver necessidade de mudar, visto terem encontrado

no seu dia a dia navegadores e dispositivos de acesso extremamente tolerantes a

HTML inválido e mal estruturado. Como resultado disto, muitos ainda oferecem

grande resistência à ideia de haver necessidade de aprender novas e melhores

formas de criar sítios web. Muitos argumentarão que com o uso de CSS para o

estabelecimento do layout de uma página é impossível criar um design perfeito

que recrie exactamente aquilo que têm em mente.

Uma má implementação da norma CSS em navegadores mais antigos pode ter

criado resistência alguns autores na adopção destes novos standards. A verdade é

que os navegadores mais recentes, bem como os que estarão para vir, estão a



mover-se no sentido contrário de serem menos tolerantes com as falhas e a

obrigar à produção de código normalizado e virado para o futuro.

6.6. O que fazer com os sítios já existentes

Quando se pretende converter às normas um sítio que tenha sido anteriormente

criado sem as respeitar, a melhor forma de abordar o problema é através de uma

estratégia de conversão incremental.

O caminho em direcção a um sítio em conformidade com as normas é um processo

que pode inciar-se com a escolha das normas que se pretende cumprir e

determinar a melhor estratégia para tornar o sítio acessível. Uma ferramenta

desenvolvida pelo W3C, o Log Validator, pode ajudar neste processo. Esta

ferramenta analisa os logs dos servidores web e verificam a validade das páginas

mais frequentemente visitadas, ajudando a detectar e corrigir erros. Tornando

periódico este processo, é possível partir das páginas mais visitadas, logo mais

importantes, e progressivamente ir corrigindo todo o sítio.

6.7. Aplicar as normas em sítios web novos

Um novo projecto web é a oportunidade ideal para a aplicação das normas desde

o início da construção do sítio web, ou seja, incorporar as boas práticas de

desenvolvimento web desde as fundações do projecto.

Qualquer que seja o tipo de projecto web, é essencial especificar desde o início

quais as normas que deverão ser consideradas e escrupulosamente respeitadas e

aplicadas.



Se para a gestão do sítio for indispensável a utilização de um sistema de gestão de

conteúdos, deve considerar-se a capacidade que este possui ou não de produzir

código normalizado. Pode ser necessária a adição de módulos independentes que

dotem o sistema de gestão da capacidade de escrever código que respeite as

normas. Caso não exista essa possibilidade, deve considerar-se a utilização de

sistemas livres semelhantes, que disponibilizam o código fonte da aplicação que

poderá ser alterado para cumprir com as necessidades específicas do projecto, seja

pelo próprio autor do projecto, seja com a ajuda das comunidades que

normalmente estão ligadas a este tipo de software.

Para assegurar que o sítio continua de acordo como o inicialmente projectado,

deve exigir-se a manutenção da conformidade com as normas durante cada fase

do ciclo de vida do sítio web, projecto, desenvolvimento, teste e manutenção. É

preciso assegurar que, em cada fase, todos aqueles que contribuem para o sítio

sejam capazes de criar e manter as páginas correctamente. É importante

continuar com a exigência para além dos estágios inciais. Para tirar todo o

benefício da utilização das normas é necessário que o sítio mantenha sempre o

respeito por estas.

6.8. Validação para controlo de qualidade

6.8.1. O que é a validação

A validação é o processo através do qual se pode verficar a correcção das páginas

web. É uma forma simples de assegurar que um sítio web caminha em direcção às

normas. Visto as tecnologias HTML e CSS serem linguagens formais, este

processo consiste em verificar a validade o código contido nesses documentos de

acordo com a gramática formal definida pelo Document Type Definition, DTD,

de forma semelhante à verificação de erros gramaticais nos textos escritos em

processadores de texto, por exemplo.



As ferramentas que validam o conteúdo de páginas web sáo conhecidas como

validators. Estas ferramentas encontram-se livremente disponíveis no sítio do

World Wide Web Consortium e podem ser utilizadas para verificar documentos

individuais. Outras existem que podem verificar a validade um sítio inteiro, mas

têm geralmente um custo associado. No entanto, as ferramentas mais actualizadas

e que, por razões óbvias, devem ser utilizadas são as que o W3C disponibiliza.

Os programas de validação alojados pelo W3C estão permanentemente

actualizados e em sintonia com o grau de desenvolvimento das normas que

validam. Podem ser consultados nas seguintes localizações:

§ Para validar HTML – http://validator.w3.org/

§ Para validar CSS – http://jigsaw.w3.org/css-validator/

6.8.2. A validação é uma parte importante do controlo de

qualidade

Problemas como comportamentos inesperados ou problemas de layout podem

ocorrer devido a simples erros na produção de HTML ou de CSS. A validação do

conteúdo das páginas permite encontrar e remover erros formais, melhorando a

apresentação dos documentos corrigidos em todos os dispositivos de acesso.

A validação é:

§ a mais fácil e barata forma de controlo de qualidade do HTML e CSS em

que as páginas de um sítio estão escritas;

§ uma forma eficaz de detectar erros humanos devidos a distração ou

desconhecimento das normas;

§ um método de avaliar a qualidade de trabalho da equipa de

desenvolvimento;



§ uma maneira simples de encontrar erros difíceis de encontrar a olho nú, de

forma semelhante ao uso de correctores ortográficos num processador de

texto;

§ o método mais simples de assegurar a conformidade das páginas

constituintes de um sítio.

6.8.3. Compreender o resultado das ferramentas de validação

À primeira vista, o resultado que nos é apresentado após a validação de uma

página por uma das ferramentas do W3C pode parecer pouco claro e por vezes

incompreensível. Visto ser uma ferramenta perfeitamente automatizada, o

software apresenta todos os erros existentes e tenta providenciar uma explicação.

Após a correcção do primeiro erro mostrado e uma nova passagem pela

ferramenta de validação, o número de erros é geralmente reduzido. Isto deve-se

ao facto de um simples erro poder gerar uma reacção em cadeia que pode causar

erros adicionais. Depois de utilizar estas ferramentas algumas vezes, ganha-se um

maior conhecimento do significado das mensagens de erro e a causa do erro é

mais fácil de detectar e corrigir.



7. Normas Emergentes e

Futuras

7.1. XForms

7.1.1. Formulários web

A submissão de dados num sítio web e seu posterior tratamento é, muitas vezes, a

sua mais importante funcionalidade. Desde o registo de um utilizador numa

newsletter, à adição de elementos a um carrinho de compras, passando pelo envio

de um mensagens através de um webmail, um sítio web está constantemente a

pedir a inserção de informação ao utilizador através de um típico formulário

HTML, elemento constituinte do HTML desde muito cedo. Agora, uma

alternativa surge sob a forma de uma nova geração de formulários web, os

XForms, sob a orientação do W3C.

Uma das maiores desvantagens do uso tradicional de HTML é a necessidade de

se socorrer de tecnologias alternativas como o JavaScript ou linguagens server-

side como o PHP ou o Perl. Embora seja difícil garantir a exactidão de todos os

dados inseridos pelo utilizador, os programadores responsáveis tentam, pelo

menos, exercer algum controlo sobre a sua estrutura sintáctica. Quando um

endereço de e-mail é pedido, a norma é verificar se corresponde à estrutura típica

de [email protected]ÍNIO, ou quando um número de telefone é requisitado,

existe normalmente uma verificação para assegurar que o número indicado é

apenas composto por dígitos e com o número de algarismos correcto.



Para um conjunto simples de dados, um grupo de funções JavaScript é capaz de

exercer a validação necessária. Para um conjunto mais complexo, pode haver a

necessidade de recorrer a uma validação do lado do servidor, o que leva à

existência de mais comunicação entre cliente e servidor, aquando do envio dos

dados e da resposta à validação desses mesmos dados de volta ao cliente.

A tecnologia XForms providencia uma solução a nível do cliente que evita que a

comunicação extra com o servidor, tal como a existência de código de validação

do lado de servidor seja necessário. Esta norma, desenvolvida pelo W3C, poderá

tornar-se parte integrante do desenvolvimento web nos próximos tempos.

Tal como outras tecnologias emergentes, os Xforms apenas podem ainda ser

executados através da adição aos navegadores de plug-ins ou de aplicações

autónomas desenvolvidas apenas para o efeito.

7.1.2. Aplicações de render de XForms

Entre os motores actuais para a execução de XForms encontram-se as aplicações

XForms Explorer, desenvolvido pela Novell, e X-Smiles, desenvolvido pela

Universidade de Helsínquia. Ambas estão desenvolvidas em Java, logo capazes de

correr em várias plataformas. O desenvolvimento de plug-ins para a visualização

de XForms em navegadores encontra-se estendido por vários projectos diferentes

com diferentes níveis de maturidade, mas os referidos são so que se encontram

mais completos e estáveis.



7.1.3. Exemplo práctico

O código seguinte ilustra uma utilização simples da tecnologia XForms:

<html xmlns="http://www.w3.org/1999/xhtml"

xmlns:xform="http://www.w3.org/2002/xforms"

xmlns:ev="http://www.w3.org/2001/xml-events"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<head>

<title> One way reservation system </title>

<xform:model>

<xform:submission action="/xformsprocessor.jsp" id="submit" method="post"/>

<xform:instance src="flightmodel.xml"/>

<xform:bind ref="/flight/departure" type="xsd:date"/>

<xform:bind constraint=". > 0" ref="/flight/adults/number" type="xsd:integer"/>

<xform:bind constraint=". > 0" ref="/flight/children/number" type="xsd:integer"/>

<xform:bind calculate="(/flight/adults/number * /flight/adults/price) +

(/flight/children/number * /flight/children/price)"

ref="/flight/total"/>

</xform:model>

</head>

<body>

<h4 align="center"> One way reservation system </h4>

<table align="center" border="5">

<tr><td> From : Anywhere </td><td> To : Anywhere </td></tr>

<tr><td> <xform:output ref="/flight/adults/price">

<xform:label style="font-weight:bold;">Adults</xform:label>

</xform:output> </td>

<td> <xform:output ref="/flight/children/price">

<xform:label style="font-weight:bold;">Children</xform:label>

</xform:output> </td> </tr>

<tr><th> <xform:input ref="/flight/adults/number">

<xform:label style="font-weight:bold;">No.of Adults </xform:label>

</xform:input> </th>

</tr>

<tr><th> <xform:input ref="/flight/children/number">

<xform:label style="font-weight:bold;">No. of Children </xform:label>




</tr>

<tr><th> <xform:input ref="/flight/departure"> <xform:label style="font-weight:bold;">Departure date</xform:label>


</tr>

<tr><th> <xform:output ref="/flight/total">

<xform:label style="font-weight:bold;">Total</xform:label>

</xform:output> </th>

</tr>

<tr><td> <xform:submit name="Submit" submission="submit">

<xform:label>Reserve</xform:label>

</xform:submit>

<xform:trigger>

<xform:label>Reset</xform:label>

<xform:reset ev:event="DOMActivate"/> </xform:trigger>

</td></tr>

</table>

</body>

</html>

Listagem 1 – Código XForms

De início declaram-se os típicos elementos de um documento XHTML, como as

etiquetas <HTML>, <HEAD> e <TITLE>, com a adição de três namespaces para os

elementos XForms, XML-Events e XMLSchema.

A primeira parte do XForm está incluída dentro do elemento head, e inclui uma

série de estruturas lógicas definidas na etiqueta <XFORM:MODEL>. O elemento

XFORM:SUBMISSON declara a página do lado do servidor que vai processar os

dados do XForm, enquanto que XFORM:INSTANCE define o modelo de dados XML

que será utilizado no XForm.

Neste caso, o documento FLIGHTMODEL.XML tem a seguinte estrutura:

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

<flight>

<departure>2004-05-24</departure>

<adults>

<number>0</number>



<price>120</price>

</adults> <children>

<number>0</number>

<price>60</price>

</children>

<total>0</total>

</flight>

Listagem 2 - Modelo de dados XForms

Com os dados instanciados, segue-se a definição de restrições ou procedimentos

lógicos utilizando os elementos do tipo XFORM:BIND. A primeira declaração

restringe o elemento departure a uma data normalizada pelo Schema. A estrutura

sintáctica é baseada na tecnologia XPath. De seguida, definem-se ambos os

elementos númericos como sendo inteiros positivos, através dos atributos TYPE e

CONSTRAINT. Por fim, declara-se a operação matemática através do atributo

CALCULATE e coloca-se o resultado correspondente no elemento TOTAL. Com o

modelo do XForm definido, segue-se a construção do resto do documento

XHTML, no qual se incluirá o código que indica os elementos XForm que serão

apresentados. As duas primeiras declarações utilizam o elemento XFORM:OUTPUT

para mostrar uma parte do modelo de dados propriamente dito. Utilizando o

atributo REF, são invocados dois elementos PRICE definidos no modelo. De

seguida, definem-se dos elementos XFORM:INPUT que geram duas caixas de texto

para permitir ao utilizador a inserção de informação. Cada um destes elementos

define também um atributo REF que referencia o modelo de dados. Por fim, está

definido o elemento XFORM:SUBMIT utilizado para gerar um botão de submissão,

bem como um elemento XFORM:RESET que gera um botão de reinicialização,

retornando o formulário ao seu estado inicial.

A figura seguinte, Figura 4, representa o XForm anteriormente referido a correr

na aplicação autónoma X-Smiles.



7.1.4. XForms, alternativa de futuro

Podemos encontrar as seguintes particularidades neste tipo de formulário:

Figura 4 - Formulário Xform

§ Cada mudança efectuada num elemento de input automaticamente dispara

uma modifcação no modelo de dados que se propaga à visualização do

formulário no navegador propriamente dito.

§ Se os dados inseridos estiverem fora do âmbito definido pelo modelo de

dados, os erros serão indicados pelo navegador, que os sublinha.

§ A carga transferida para o servidor é equivalente ao modelo de dados

XML definido.

Embora estejam aqui descritas as avançadas capacidades lógicas da tecnologia

XForms, a especificação tem um âmbito muito mais alargado permitindo outras

operações e usos de elevada utilidade e capacidade. A sua fácil integração com o

XML e a previsão de que a tecnologia XForms seja também suportada por

dispositivos móveis, desde logo permite considerar que esteja no bom caminho

para ser uma norma com lugar de destaque no futuro da web.



7.2. SVG, Scalable Vector Graphics

7.2.1. Curta história do SVG

Ao longo dos últimos anos, tem existido um crescente interesse pelo uso de

gráficos e animações vectoriais. Em 1999, o World Wide Web Consortium

iniciou o desenvolvimento de um formato aberto chamado Scalable Vector

Graphics. A Especificação SVG 1.0, publicada em Setembro de 2001, oferece a

possibilidade de ter gráficos e animações simples semelhantes às conseguidas com

o formato SWF da Macromedia, bem como outras características adicionais.

Como uma aplicação do XML, a norma SVG 1.0 está mais integrada com outras

tecnologias web que o SWF. A Recomendação SVG 1.0 tem um apoio

considerável da indústria, tendo empresas como a Adobe, a Apple, a Canon, a

Corel, a Hewlett-Packard, a Macromedia, a Microsoft, a Kodak, a Sun e muitas

outras contribuído para a sua especificação.

O Grupo de Trabalho SVG continua a promover o SVG através do

desenvolvimento de novas características e funcionalidades a pedido da

comunidade Web.

7.2.2. O SVG ganha cada vez mais apoio

A sua conformidade e integração com outras normas web tem permitido um

crescente interesse no SVG da parte dos criadores e autores web, mas a

tecnologia continua à espera de ter uma aceitação generalizada dos fabricantes de

browsers que lhe permita ser suportada nativamente pelos dispositivos de acesso

mais relevantes no mercado. Existem variadas razões que permitem considerar

que a tecnologia tem todas as condições para que assim aconteça num futuro

próximo.



Primeiro, a norma SVG já foi aceite como tal, visto o W3C já ter declarado o

standard SVG como uma Recomendação W3C. Além disso, tudo parece

encaminhado para uma aceitação global quando várias companhias de peso no

mercado contribuem para a criação de uma norma consensual, a declaram aberta a

todos e competem entre si na tentativa de a suportar nos seus productos.

Em segundo lugar, as pessoas já podem ver conteúdo SVG e habituar-se a tirar

partido das suas características e funcionalidades. Existem várias implementações

diferentes de aplicações capazes de interpretar o formato e mostrá-lo

correctamente. A mais popular entre elas é o plug-in da Adobe que permite a

visualização de conteúdo SVG nas plataformas Linux, Solaris, Mac OS desde a

versão 8.5 e Windows e na grande maioria dos navegadores capazes de correr nos

referidos sistemas operativos, como o Internet Explorer, Netscape, Mozilla,

Firefox, Opera e muitos outros. A Adobe afirmou publicamente a distribuição de

milhões de cópias do seu software Adobe SVG Viewer através do download

gratuito do seu sítio e do seu envio junto com produtos seus, como o Adobe

Acrobat Reader. Além disso, a Mozilla Foundation já tem um projecto que visa a

implementação do SVG como parte dos seus navegadores.

Por último, as ferramentas de desenvolvimento de conteúdo SVG estão

disponíveis. Várias aplicações possuem já a capacidade de criar informação nesse

formato e o número de aplicações que o fazem continua a crescer. Naturalmente, a

Adobe dotou o seu software profissional de desenho vectorial, Adobe Illustrator,

dessa capacidade tal como o fazem ferramentas como o WebDraw da Jasc e o

CorelDraw entre outras. Em desenvolvimento estão também ferramentas

especificamente criadas para a geração de conteúdo SVG, tal como o Adobe

AlterCast, o Corel Deepwhite e o Apache Batik, que tem a vantagem de ser livre e

de fonte aberta.



7.2.3. Legibilidade é uma grande vantagem

Apesar de,normalmente, não trazer grandes vantagens a uma imagem o facto de

ser legível, é inegável que essa é uma das melhores características do SVG. A

possibilidade de aceder a um qualquer sítio web e consultar o código fonte

HTML que gerou a página, e o facto de este código ser perfeitamente legível e

compreensível, permite a aprendizagem de muitos, encorajando-os a aprender

como o HTML funciona e conquistando o seu interesse. Outro benefício trazido

por essa capacidade de consultar o código HTML, consiste na fácil localização,

identificação e correcção de erros de uma forma mais rápida.

A legibilidade do formato SVG também traz vantagens ao nível da acessibilidade.

Uma pessoa com dificuldades visuais que esteja a consultar a web com um

navegador de síntese de voz certamente terá dificuldades em perceber uma

imagem. Com o SVG, o navegador terá a possibilidade de indicar ao utilizador,

por exemplo, o conteúdo de um gráfico, visto que a sua estrutura e valores estão

representados textualmente na própria imagem. Se ocorrer o caso de a deficiência

visual se ficar pela incapacidade de distinguir ou reconhecer adequadamente as

cores, o daltonismo, facilmente o utilizador pode criar uma folha de estilo que lhe

permita alterar as cores da imagem, por forma a possibilitar a correcta leitura da

mesma.

7.2.4. Gráficos baseados em XML fazem sentido

Sendo o XML a tecnologia a partir da qual várias outras tecnologias são

desenvolvidas, faz sentido adaptar o seu uso para descrição de imagens. Faz tanto

sentido identificar semanticamente as estruturas de um texto, como identificar as

partes integrantes de uma imagem.



Claro que a estruturação de uma imagem como uma colecção de primitivas

gráficas, como círculos, linhas ou rectângulos, não adiciona muito, mas sempre

adiciona algo. Estruturas com organização semântica ajudam à acessibilidade e,

sendo o XML o formato de informação estruturada dominante na web, uma série

de ferramentas podem ser adaptadas sem custos à criação de conteúdo SVG.

Assim sendo, e visto o SVG ser XML na sua essência, existe a opção de adicionar

informação semântica ao documento, descrevendo partes da imagem através da

norma RDF, ou qualquer outro tipo de metadados XML. Até XHTML pode ser

incluído na descrição de cada elemento.

Com o XML também se consegue integração. A utilização de imagens baseadas

em XML, como o SVG, permite que sejam integradas facilmente no workflow

existente. As ferramentas e tecnologias existentes não necessitarão de adaptação

a um novo tipo de informação, sendo que tecnologias como o DOM e XSLT, bem

como linguagens como o JSP, ASP e PHP já possuem os mecanismos para

interagir com dados XML.

Como exemplo de integração, podemos considerar o caso de um autor que cria

um modelo SVG, e depois aplica transformações para adaptar esse modelo às suas

necessidades, seja criar um cartão de negócios, seja criar um postal de natal.

Quase todas as linguagens de programação actuais possuem suporte para XML.

Se trabalharmos com XML, as ferramentas trabalharem com XML, faz todo o

sentido que a informação visual seja representada em XML também.

7.2.5. Documentos SVG e a largura de banda

Se considerarmos a tradicional forma de criar animação, podemos perceber que o

SVG permite poupar a largura de banda. A quantidade de informação necessária

para indicar que o objecto X se vai mover de A para B em dez segundos, é



claramente menor que a correspondente animação desenhada frame a frame, com

o objecto desenhado em cada uma das posições.

Outro factor a considerar, é a possibilidade de efectuar compressão de ficheiros

SVG. O Grupo de Trabalho SVG decidiu utilizar a compressão GZip na

implementação de ficheiros SVG comprimidos e tornar obrigatório o seu suporte

em cada tecnologia que os pretenda visualizar.

7.2.6. SVG e a comunidade de dispositivos móveis

Quando o W3C tornou a norma W3C uma sua Recomendação, a comunidade de

dispositivos móveis imediatamente adoptou o formato. Empresas da dimensão da

Nokia e da Ericsson, juntaram-se ao Grupo de Trabalho SVG. Tendo em conta o

reduzido tamanho dos actuais dispositivos móveis, é clara a necessidade de um

formato de imagem vectorial. Os requisitos de que esse formato fosse aberto,

baseado em XML e modularizado, para além de ser facilmente integrável com a

restante arquitectura de XHTML Basic, CSS e SMIL, tornaram o SVG a solução

óbvia.

A organização de standards para dispositivos móveis 3rd Generation Partnership

Project, 3GPP, que define a plataforma sobre a qual vão assentam os terminais

móveis de terceira geração para a Europa e Estados Unidos, escolheu a norma

SVG Tiny como o formato de imagem para mensagens multimédia.



7.2.7. SVG e a Web

A norma SVG enquadra-se na perfeição na actual arquitectura global da web

pelas seguintes razões:

§ Sintaxe do XML: Os benefícios da sua base XML já foram discutidos neste

capítulo, mas existem alguns pontos dignos de referência. Tendo a sintaxe

de um documento XML, o código SVG pode ser perfeitamente integrado

com outros documentos XML, como uma página web codificada em

XHTML. O SVG pode também ser combinado com documentos MathML

para criar representações matemáticas das fórmulas e ser combinado com a

tecnologia XForms para integrar formulários nas imagens vectoriais;

§ Web Services: O SVG encaixa perfeitamente como formato gráfico nos

Web Services quando o objectivo é atingir integração e interoperabilidade

com outras tecnologias XML. Sendo XML, os diagramas ou animações

SVG podem facilmente ser encapsuladas numa mensagem SOAP. Além

disso, a interactividade de capacidades programáticas do SVG permitem a

construção de interfaces gráficos mais complexos para os Web Services;

§ Estilo com CSS: a norma SVG é estilizável através do uso de CSS, da

mesma forma que o HTML o é. O lema é, como sempre, separar estrutura

e conteúdo de apresentação, conferindo maior acessibilidade à imagem;

§ Animação com SMIL: o SVG utiliza a mesma sintaxe de animação da

tecnologia SMIL. Isto faz com que um ficheiro SVG autónomo possa

representar animação, mas também permite a sua inclusão numa

apresentação multimedia SMIL, permitindo a integração de animação

vectorial com componentes áudio e vídeo;



§ Scripting: Qualquer atributo, propriedade ou elemento constituinte de um

documento SVG por ser modificado através de scripts. A combinação de

ECMAScript, o Javascript standard, permite a adição de funcionalidades

muito interessantes, como a modificação dinâmica dos elementos da

imagem;

§ O DOM: Sendo XML, o SVG partilha com com a estrutura mãe o seu

DOM completo. Assim sendo, os programadores não precisam de aprender

um novo interface de programação para trabalhar com o SVG. Além disso,

a norma SVG possui também uma extensão ao DOM original que fornece

modelos gráficos completos para os programadores, incluindo funções

úteis para operações comuns como a multiplicação de matrizes.

7.2.8. Formato de futuro

Considerando todos estes factores apresentados, fica claro que a norma SVG foi

projectada para ser um componente importante da arquitectura web. A adopção

de soluções abertas e baseadas em normas assegura que as partes se juntam todas

para formar um todo extensível, poderoso e económico.

O SVG não foi projectado para substituir nenhuma das tecnologias existentes.

Antes, foi projectada para ser a melhor solução de gráficos vectoriais para a web.

O formato SWF é extremamente popular e poderoso, mas também proprietário.

Encontra-se perfeitamente estabelecido no mercado e possui uma ferramenta de

produção, Macromedia Flash, extremamente popular. O SVG é um novo formato,

baseado em XML, globalmente reconhecido como sendo tecnicamente superior,

mas ainda não atingiu a mesmo nível de popularidade. Mas, com o entusiasmo

mostrado pelas pessoas que presentemente desenvolvem conteúdo SVG e com o

forte apoio da indústria e comunidade open source, não faltará muito para que o



SVG possua as ferramentas necessárias para que possa ser o novo e dominante

formato gráfico para a web.

7.3. Web Semântica

A Web Semântica é um projecto que pretende criar um meio universal de troca de

informação atribuindo significado, de maneira perceptível por máquinas, ao

conteúdo dos documentos na web.

Presentemente, a web é dominada pelos documentos escritos em HTML, uma

linguagem útil para a disponibilização de conteúdos que podem ou não ter

informação visual associada. Um documento web consiste de um corpo de texto

estruturado, intermediado por elementos multimédia como gráficos ou por

formulários interactivos. O HTML tem uma capacidade limitada de classificar

blocos de texto numa página, num contexto maior que aquele definido pela

organização do próprio documento.

A Web Semântica ultrapassa esta limitação, através do uso de tecnologias

descritivas como RDF e OWL e da altamente costumizável linguagem XML, tal

como recomendado pelo World Wide Web Consortium. Estas tecnologias são

combinadas por forma a fornecer descrições que complementam o conteúdo de

um documento web. Essas descrições legíveis e perceptíveis a máquinas permitem

a gestores de conteúdo a adição de significado ao conteúdo, facilitanto assim a

pesquisa e a recolha automática de informação.



7.3.1. A forma correcta de pesquisar

RDF significa Resource Description Framework. Esta tecnologia foi construída

para a web, mas vamos por momentaneamente a web de parte e considerar dois

cenários reais:

§ Na biblioteca: e stando numa biblioteca e procurando informação sobre

animais, o ideal será consultar uma base de dados onde constem os dados

dos livros, seja em papel ou num computador. Considerando, devido à

flexbilidade permitida, este último caso de uma base de dados disponível

num computador, podemos gerar listas de livros através de pesquisas ao

sistema por data, autor, título, assunto, etc. A lista poderá retornar dados

importantes sobre o livro, incluindo a sua localização na biblioteca.

§ A lista telefónica: num dia em que o trabalho se prolonga para além das

horas habituais, pode surgir a necessidade de encomendar uma refeição que

possa ser consumida no próprio local de trabalho. Como tal, e na ausência

dos habituais folhetos distribuídos pelas companhias de fast food, a solução

está na consulta da lista telefónica.

O que terão em comum as duas situações anteriormente descritas? Em primeiro

lugar, ambos os sistemas são baseados em metadados, ou seja, dados sobre dados,

ou informação sobre informação. Em cada caso, existe a necessidade de uma

determinada informação. Em cada caso também, utilizam-se metadados para se

obter a informação desejada. Os metadados existem, geralmente, sob a forma de

categorias, como autor ou título no caso da biblioteca, ao qual se associam os

dados relevantes para essas categorias.

Um ponto relevante é o de que, em teoria, os metadados não são realmente

essenciais. É possível percorrer toda a biblioteca até encontrar o livro pretendido,



ou telefonar a todos os número existentes até acertar no número certo da cadeia

de fast food que se deseja. Esse tipo de procedimento seria, no mínimo, pouco

inteligente. Logo, a utilização de metadados é o caminho a seguir.

Em cada um dos cenários são utilizados metadados de forma bastante similar. No

entanto, cada um dos cenários usa uma diferente configuração de metadados.

Cada um utiliza o seu próprio sistema, o que lhe pareça mais conveniente e

funcional e tipicamente não existe a preocupação de dotar os sistemas da

capacidade de partilha e intercâmbio de dados.

7.3.2. Na web

A web é, na verdade, uma biblioteca de dimensões prodigiosas. Nela existe

informação sobre os mais variados assuntos e temas e, se soubermos o URL

correcto, tal como um número de telefone, podemos aceder a esses conteúdos

directamente. Porém, o uso de metadados na web é ainda muito escasso e está

pouco dessiminado. Mas o interesse nesta matéria é cada vez maior, tal como é

crescente a consciência de que a aplicação e uso devido de metados na web é de

extrema importância.

O problema surge pelo facto de cada aplicação, pessoa ou organização ter as suas

próprias necessidades e objectivos. Não é possível obrigar a todos os autores web

a inserirem metadados nos seus documentos, tal como é difícil normalizar a sua

utilização, unificando o uso de metadados sobre uma mesma norma. As diferentes

necessidades e objectivos de cada um dificultam a normalização, mas a verdade é

que, tal como observamos antes nos cenários apresentados, existem pontos

comuns. O RDF nasce da necessidade de identificar estas similaridades e permitir

que os gestores de informação as usem e dotem cada documento web de

informação sobre o seu conteúdo.



7.3.3. Resource Description Framework

O RDF, Resource Description Framework, tal como o próprio nome indica, é

uma infraestrutura criada para a descrição de intercâmbio de metados. Foi

construído assente nas seguintes regras:

§ Um Recurso é tudo que possa ter um URI, Uniform Resource Identifier,

como qualquer página web ou um elemento individual de um documento

XML.

§ Uma Propriedade é um recurso que possui um nome e pode ser usado

como um atributo como um autor ou um título de um livro. Uma

Propriedade deve ser também um Recurso para que, por sua vez, possa ter

propriedades suas.

§ Uma Afirmação consiste da combinação de um Recurso, uma Propriedade

e um valor. Estas três partes são conhecidas por sujeito, predicado e

objecto de uma Afirmação. Como exemplo de Afirmação, podemos

considerar “O Autor de http://www.domain.com/page.html é Sérgio

Lopes”. Neste caso, o valor pode ser “Sérgio Lopes”. O valor pode também

ser ele próprio um recurso, como podemos verificar na afirmação “A

página inicial de http://www.domain.com/page.html é

http://www.domain.com/index.html”.

§ Uma forma de descrever estas propriedades é através do uso de XML,

como por exemplo:

<rdf:Description about='http://www.domain.com/about.html'>

<Author>Sérgio Lopes</Author>

<Home-Page rdf:resource='http://www.domain.com/index.html' />

</rdf:Description>

Listagem 3 - Código RDF



A norma RDF foi projectada para possuir as seguintes características:

§ Independência: visto uma propriedade ser também um recurso, qualquer

pessoa ou organização pode criar as suas. Uma organização pode criar uma

denominada Autor, enquanto outra cria outra denominade Criador;

§ Intercâmbio: porque uma afirmação RDF pode ser convertida em XML,

estas são fáceis de integrar e utilizar entre aplicações;

§ Escalabililidade: as afirmações RDF são simples e tripartidas, recurso,

propriedade e valor, logo são fáceis de utilizar e gerir mesmo quando em

grande número. A web é um universo cada vez maior e existirá um número

de afirmações de elevada ordem de grandeza a serem transferidas

constantemente;

§ Propriedades e Recursos: as propriedades podem ter as suas próprias

propriedades e podem ser manipuladas como qualquer outro recurso e,

como tal, podem ser pesquisadas. Pode pesquisar-se por propriedades que

tenham determinado valor.

§ Valores podem ser recursos: por exemplo, a maior parte das páginas web

possuem uma propriedade denominada página inicial, ou home page, esteja

ou não definida explicitamente. Assim, as propriedades, além de poderem

assumir valores como Título ou Autor de um documento, podem também

assumir como valor um recurso.

§ Afirmações podem ser recursos: as afirmações também podem possuir

atributos. Por exemplo, para a afirmação “O assunto deste documento é

RDF”, podem ser colocadas questões como “Quem o determinou?” ou

“Quando o determinou?”. Assim, as afirmações são também elas recursos

que possuem propriedades.



7.3.4. Porque não usar apenas XML?

O XML permite a criação de etiquetas adaptadades às nossas necessidades, que

podem conter informação textual ou outras etiquetas. É um mecanismo standard

para a estruturação de dados. O Resource Description Framework, RDF, é um

mecanismo para dar informação sobre os dados, ou seja, para lhes dar significado.

Uma falha significativa pode ser encontrada no uso de XML para estes propósitos

quando é analisada a sua escalabilidade. Por exemplo, a ordem pela qual estão

estruturados os dados num documento XML é importante. No entanto, não é

muito relevante a ordem pela qual aparecem os metadados. É irrelevante, na

descrição de um filme, a ordem pela qual a informação aparece, se o primeiro a ser

representado é o seu realizador ou o seu título. Além disso, a gestão da ordem e a

sua correcta manutenção de dados em número de elevada ordem de grandeza é

difícil e financeiramente dispendiosa. A própria representação de um documento

XML em memória é de extrema complexidade. Embora não deva ser esquecido

que o XML é uma parte essencial para o RDF, visto ser uma solução inigualável

em processos de troca de informação na web, é visível que o XML, por si só, não é

capaz de se afirmar como uma infraestrutura de gestão de metadados.

7.3.5. Vocabulários

Como já foi descrito, o RDF apresenta um modelo para os metadados e uma

sintaxe para que diferentes entidades possam usar e trocar informação entre si. O

que não possui são propriedades já determinadas. A norma RDF não define a

propriedade Autor ou Realizador. Essa é uma tarefa que deve ser levada a cabo

por todas as pessoas envolvidas.

No que se refere às propriedades, é pouco provável que uma propriedade tenha

valor por si só. Se estiverem incluídas em pacotes que integrem outras

propriedades relacionadas e relevantes, o seu valor aumenta consideravelmente



como conjunto, como por exemplo um possível conjunto de propriedades

biblográficas como Autor, Título, Data, Editora, entre outros. Estes pacotes de

propriedades são chamados de Vocabulários. É previsível, caso a tecnologia venha

a ser amplamente aceite, o surgimento de vocabulários para a descrição de livros,

vídeos, músicas e de muitos outros dos variados recursos que pululam na web.

7.3.6. O que pode significar o RDF

O conteúdo da web é demasiado grande para poder ser controlada por apenas

uma pessoa. De facto, contém informação sobre os mais variados assuntos, e cada

um deles pode ser tão vasto e ter tanta informação disponível que esse controlo é

impossível. Assim, é de extremo valor qualquer possível ajuda na busca de

informação como apontadores ou índices. Não se espera que todos usem o mesmo

vocabulário, até porque seria errado fazê-lo, mas com o RDF pode existir todo

um mercado de vocabulários. Os melhores, ou melhor publicitados, sobreviverão

e prosperarão. Alguns nichos de informação serão dominados por um pequeno

número de vocabulários, tal como a catalogação feita pelas bibliotecas hoje em

dia.

E, mesmo aqueles que usam os mesmos vocabulários de metadados, não têm a

necessidade de utilizar o mesmo software. A tecnologia RDF permite o uso de

diferentes aplicações no processamento dos mesmo metadados, ou o uso de uma

só aplicação para processar diferentes vocabulários. Com alguma sorte e empenho

de todos os envolvidos no processo de desenvolvimente e divulgação desta

tecnologia, talvez seja possível transformar a web em algo mais semelhante a uma

biblioteca.

7.3.7. Linguagens de Ontologia

Uma ontologia define os termos utilizados para descrever e representar uma

determinada área de conhecimento. As ontologias são utilizadas por pessoas,



bases de dados e aplicações que necessitam de partilhar informação dentro de um

domínio, sendo que domínio é um determinado assuntou ou área de conhecimento

como a medicina, biologia, informática, gestão financeira, entre outros. As

ontologias incluem definições utilizáveis por computadores de conceitos básicos

em determinado domínio e as suas relações entre eles.

A Web Semântica necessita de ontologias que possuam um grau significativo de

estrutura. Estas devem especificar descrições para os seguintes conceitos:

§ Classes de um determinado domínio

§ Relações que possam existir entre os elementos de um domínio

§ Propriedades que esses elementos possam ter

As ontologias sáo geralmente representadas numa linguagem baseada em lógica,

por forma a que se possam realizar distinções detalhadas, precisas, consistentes e

significativas entre classes, propriedades e relações.

As ontologias são uma figura proeminente da emergente Web Semântica como

uma forma de representar a semântica de documentos e de permitir que essa

semântica seja usada por aplicações web e agentes inteligentes. Usando

ontologias, as aplicações de amanhã poderão ser mais inteligentes, pois podem

realizar um trabalho mais preciso e a um nível mais aproximado do nível

conceptual humano.

As ontologias são críticas para aplicações que necessitam de, em várias

comunidades, efectuar pesquisas e de juntar informação. Apesar dos XML DTDs

e XML Schemas serem suficientes para trocarem dados entre entidades que

tenham acordado previamente as definições utilizadas, a sua falta de semântica

impedem as aplicações de realizar essas operações de troca e junção de informação



de forma fiável. O mesmo termo pode ter subtis diferenças de sentido quando

utilizado em diferentes contextos, e termos diferentes podem ser utilizados para

representar o mesmo conceito. As tecnologias RDF e RDF Schema aproximam-

se da resolução deste problema. Com o RDF Schema é possível definir classes do

qual derivem mais do que uma sub-classe, ou que derive de mais do que uma

super-classe, bem como definir propriedades que podem ter sub-propriedades,

domínios e âmbitos. Posto desta forma, o RDF Schema consegue ser uma

linguagem de ontologia simples. Porém, para conseguir a interoperabilidade

entre vários schemas desenvolvidos e geridos autonomamente, semânticas mais

ricas são necessárias. Por exemplo, o RDF Schema não consegue especificar que

uma pessoa e um carro são classes disjuntas, ou que um quarteto de cordas tem

exactamente quatro elementos.

As ontologias foram desenvolvidas para a inteligência artificial para facilitar a

reutilização e partilha de conhecimento. Desde a década de noventa que as

ontologias se tornaram um tópico de investigação pesquisado por muitas

comunidades de investigação em inteligência artificial, entre as quais as que

envolviam a engenharia do conhecimento, o processamento de linguagem natural

e a representação de conhecimento.

Mais recentemente, o conceito de ontologia está a expandir-se até áreas como o

comércio electrónico e a gestão do conhecimento. A razão pela qual as ontologias

se estão a popularizar prende-se com o seu objectivo: uma compreensão comum e

partilhada de um determinado domínio que possa ser comunicado entre pessoas e

aplicações. Como as ontologias visam um conhecimento consensual de um

domínio, o seu desenvolvimento é muitas vezes um processo cooperativo que

envolve pessoas diferentes, possivelmente de diferentes localizações.

Muitas definições de ontologia têm sido propostas na última década. Porém, uma

das que melhor a caracteriza é a que define ontologia como uma especificação



formal e explícita de uma conceptualização partilhada. A conceptualização refere-

se a um model abstracto de determinado fenómeno, que identifica os conceitos

relevantes de mesmo fenómeno. Explícito significa que o os conceitos utilizados e

suas restrições estão explicitamente definidas. Formal traduz-se pela capacidade

de a ontologia ser perceptível a uma máquina. Partilhada reflecte a noção de que

uma ontologia possui conhecimento consensual, ou seja, não está restrita a um

indivíduo, antes é aceite por um grupo.

7.3.8. OWL, Linguagem de Ontologia para a Web

A tecnologia OWL tem como objectivo ser utilizada quando a informação contida

em documentos necessita de processamento por aplicações, ao invés de necessitar

de apenas ser apresentada a seres humanos. A OWL pode ser explicitamente

utilizada para representar o significado dos termos em vocabulários e as suas

relações entre esses termos. Esta representação de termos e as suas relações é

chamada de ontologia. A OWL permite extender as capacidades de exprimir

significado e semântica que tecnologias como XML e RDF possuem, logo é um

passo em frente na tentativa de representar na web conhecimento reconhecível

por máquinas. A norma OWL é uma revisão da linguagem de ontologia

DAML+OIL e incorpora as lições aprendidas com o seu desenvolvimento e

utilização.

7.3.9. Porquê OWL

A Web Semântica é uma visão para o futuro da web em que à informação é

atribuído um significado explícito, facilitando o processamento e integração por

aplicações da informação disponível na web. A Web Semântica é assente na

capacidade do XML em definir novos esquemas de etiquetas e na flexibilidade

permitida pelo RDF na representação de metadados. Segue-se a necessidade de

uma ontologia que possa descrever formalmente o significado da terminologia



usada nos documentos web. Se é esperado que as aplicações possam realizar

tarefas de complexidade razoável em documentos, é necessária uma linguagem

que ultrapasse a semântica básica do RDF e RDF Schema.

Resumindo:

§ O XML fornece uma sintaxe para documentos estruturados, mas não

impõe restrições semânticas para o significado desses documentos;

§ O XML Schema é uma linguagem para restringir as estruturas dos

documentos XML e estender o XML com tipos de dados;

§ O RDF é um modelo de dados para objectos ou recursos e as suas relações,

fornecendo semântica simples para esse modelo que pode ser representado

utilizando a sintaxe do XML;

§ O RDF Schema é um vocabulário para a descrição de propriedades e

classes de recursos RDF;

§ A OWL adiciona mais vocabulário para a descrição de propriedades e

classes. Entre outras, possibilita a descrição das relações entre classes, a

representação de cardinalidade, de igualdade e possibilita uma melhor

definição de propriedades e suas características.

7.3.10. As três sub-linguagens OWL

A OWL possui três sub-linguagens projectadas para o uso de comunidades

específicas:

§ A OWL Lite destina-se aos utilizadores cuja necessidade principal passa

pelo uso de uma classificação hierárquica e de restrições simples. Por

exemplo, embora possua restrições de cardinalidade, apenas permite



valores de cardinalidade de zero ou um. Além disso, possui uma

complexidade formal que a sub-linguagem OWL DL.

§ A OWL DL destina-se aos utilizadores que necessitam de máxima

expressividade e de garantias computacionais de que todas as conclusões

são computáveis e que todas as computações finalizarão num espaço de

tempo finito.A OWL DL inclui todas as funcionalidades da linguagem

OWL, mas apenas utilizáveis segundo determinadas restrições. Por

exemplo, uma classe pode ser derivada de muitas classes ou uma classe não

pode ser derivada de nenhuma outra. O DL presente na designação desta

sub-linguagem deriva do termo lógica descritiva, description logic no

original inglês, uma área de pesquisa que estuda a mesma lógica utilizada

para implementar as fundações formais da OWL.

§ A OWL Full destina-se aos utilizadores que necessitam de máxima

expressividade e da liberdade sintáctica do RDF, sem garantias

computacionais. Por exemplo, na OWL Full uma classe pode ser

considerada simultaneamente como uma colecção de indivíduos e um

indivíduo em si mesma.



8. Conclusão

Futuro. Uma palavra que tem o seu quê de esotérico. O futuro é o amanhã, é o

destino, é o que há-de ser mas ainda não é. E o que nos reserva esse futuro? Mais

concretamente, que reservará esse futuro para a World Wide Web? Seja qual for

a área de estudo, saber o que nos espera no dia de amanhã é tarefa difícil, quiçá

impossível.

Desde tempos longínquos que a previsão do futuro é tentada. Geralmente, o seu

sucesso é mínimo, muitas vezes nulo. Se o destino nos trouxesse aquilo que as

sábias mentes julgavam prever, provavelmente as nossas deslocações seriam

efectuadas pelas nossas estradas em veículos flutuantes em vez dos tradicionais

automóveis, e nas férias teríamos como destino de sonho, não uma esplendorosa

ilha do Pacífico, mas sim uma das muitas colónias humanas em planetas distantes.

O futuro da web é, então, uma incógnita. Mas não será um completo manto

negro, cheio de mistérios ocultos, segredos indesvendáveis e resultados

inesperados. O futuro pode ter o seu início já hoje, se assim o quisermos. Se, em

cada acção, a nossa visão não estiver limitada ao que nos ro deia nem estiver

restringida ao imediato, se houver a vontade de olhar mais longe e mais além, o

destino poderá não trazer tão nefastas mudanças e surpresas, e estaremos

preparados com o conhecimento e as tecnologias que nos permitirão encará-lo

com um sorriso.

É primordial fazer passar a mensagem que o mundo, e a web em particular, é

muito mais do que aquilo que os nossos sentidos nos mostram e que, como tal,



necessitamos de possuir uma visão alargada. E em que se traduz, concretamente,

essa capacidade de vermos além daquilo que nos rodeia?

A primeira conclusão a tirar deste estudo é a da necessidade de dotar a web

acessibilidade, um factor cada vez mais importante na sociedade actual. Neste

caso, ter visão implica perceber que não devemos limitar o acesso à informação de

pessoa alguma, que todos temos o direito de aceder aos mesmos recursos,

independentemente das nossas características físicas e dos recursos materiais e

financeiros ao nosso dispor. O aumento do número de pessoas capazes de aceder

aos recursos por nós disponilizados, para além de assegurar que existe

descriminação de qualquer tipo, possibilita um aumento de visibilidade que, não

raras vezes, se traduz por um aumento de receitas também.

Continuando, ter visão implica perceber que a socidade de hoje evolui a um ritmo

cada vez maior. O que hoje impera, amanhã não passa de uma breve lembrança.

Essa é a segunda conclusão produzida por este estudo. Sendo assim, é importante

desenvolver projectos com bases sólidas que permitam a sua evolução fut ura.

Poder evoluir, desenvolvendo o trabalho sobre sólidas fundações, sem haver

necessidade de perder o trabalho até então desenvolvido, é uma mais-valia

fundamental.

A constante evolução da web, assente sobre as tecnologias do passado e do

presente, é a terceira conclusão possível do estudo. As várias tecnologias

apresentadas como exemplo das que possivelmente reinarão na web de amanhã

têm, aliás, um ponto em comum: a linguagem em que todas se baseiam. As várias

tecnologias têm como base uma linguagem de definição, estruturação e partilha

de informação por excelência, o XML.

O uso de uma tecnologia com tais características, permite retirar mais uma

conclusão, A de que a web se está a tornar uma entidade mais inteligente e, ao



invés de ser um mero repositório de informação estática e circunscrita, é cada vez

mais um espaço dinâmico onde a informação flui livremente e pode ser facilmente

pesquisada e acedida por todos, homem e máquina.

Outra conclusão que pode ser retirada do trabalho aqui apresentado é o do

crescente encorajamente para a modularização e clara separação de papéis. Cada

tecnologia deve ter o seu papel e, no caso da web tradicional, o uso de tecnologias

diferenciadas para descrever a estrutura do documento e a sua apresentação é

disto exemplo, por oposição ao uso da linguagem HTML como tecnologia multi-

usos.

Que ponto comum podemos vislumbrar em todas estas conclusões? A resposta é:

a existência de normas. Todas as tecnologias sobre as quais assentam a web do

passado, do presente e do futuro são normas projectadas, desenvolvidas,

implementadas e mantidas pela organização World Wide Web Consortium são a

espinha dorsal de uma web que é cada vez mais parte integrante do dia a dia de

cada um. A web não deve ser um meio em que cada um puxa para seu lado, mas

antes o resultado de um esforço conjunto em que todos contribuem com a sua

parte para a obtenção de um desígnio comum: uma web de todos e para todos.



9. Bibliografia

§ Zeldman, J., (2003) Designing With Web Standards, New Riders

Publishing, Indianapolis, IN, Estados Unidos da América.

§ Davies, J., Fensel, D. e van Harmelen, F., (2003) Towards The Semantic

Web – Ontology-Driven Knowledge Management, John Wiley and Sons

Ltd., West Sussex, Inglaterra.

§ Eisenberg, J. D., (2002) SVG Essentials, O’Reilly & Associates, Inc.,

Sebastopol, CA, Estados Unidos da América.

§ Jourdan, M., (2001) A formal semantics of SMIL: a web standard to

describe multimedia documents, Elsevier Science B.V.

§ Ding, Y., Fensel, D., Klein, M. e Omelayenko, B., (2002) The semantic

web: yet another hip?, Elsevier Science B.V.

§ http://www.webstandards.org

§ http://www.w3schools.com

§ http://www.wikipedia.org

§ http://www.alistapart.com

§ http://www.hotdesign.com

§ http://www.newsforge.com

§ http://www.devchannel.org

§ http://www.blakeross.com

§ http://www.csszengarden.com

§ http://www.w3.org

§ http://www.maccaws.org

§ http://www.maxdesign.com.au



§ http://www.zeldman.com

§ http://devedge.netscape.com

§ http://www.oreillynet.com

§ http://www.semanticweb.org

§ http://www.xml.com

§ http://www.webdeveloper.com

Normas Web – Tecnologias Futuraspaf/proj/Set2004/i970375-Normas Web.pdf · actual como o HTML,...

Documents

Transcript of Normas Web – Tecnologias Futuraspaf/proj/Set2004/i970375-Normas Web.pdf · actual como o HTML,...