World Wide Web.

Apresentação em tema: "World Wide Web."— Transcrição da apresentação:

1 World Wide Web

2 World Wide Web host 1 - br host 2 - ca host 3 - br host 4 - fr
rerererre ytghgfhg gfhgfhgfh nnbvnbnb ffdf 999 ooiopiopop pooopioiop poiipoiopi uiouuioui iuiouuuiui nmm,mnm rerererre ytghgfhg gfhgfhgfh nnbvnbnb rerererre ytghgfhg gfhgfhgfh nnbvnbnb jjlkdjjdjjj dsdadadd dsdasd host 3 - br ooiopiopop pooopioiop poiipoiopi uiouuioui iuiouuuiui nmm,mnm ooiopiopop pooopioiop poiipoiopi uiouuioui iuiouuuiui nmm,mnm ooiopiopop pooopioiop poiipoiopi uiouuioui iuiouuuiui nmm,mnm rerererre ytghgfhg gfhgfhgfh nnbvnbnb hfhgfh jjghjhgjhg kjlkjlllllll rerererre ytghgfhg gfhgfhgfh nnbvnbnb lljkljkl khjkhjkkk rerererre ytghgfhg gfhgfhgfh nnbvnbnb ffdf 999 ooiopiopop pooopioiop poiipoiopi uiouuioui iuiouuuiui nmm,mnm host 4 - fr World Wide Web host 5 - us

3 World Wide Web Propiciar aos usuários, a partir de uma forma unificada, acesso a documentos “hypermedia” situados em qualquer computador conectado à Internet. Os usuários navegam pelo universo dos documentos da WEB guiados pelos “hyperlinks”, através de simples “point and click” do mouse.

4 Idéias Básicas na Concepção da World Wide Web
Trata-se de um (super) sistema de informação distribuído por computadores existentes em todo o mundo. A Web é uma coleção de protocolos e padrões para acesso à informação na Internet. Suporte a “Hypermedia” - Pode-se visualizar textos, figuras, sons e animações recuperadas de computadores localizados em qualquer local do planeta. Extensibilidade: de modo que todo e qualquer formato de dados seja suportado

5 Terminologia Um objeto na WEB é um conjunto de dados na forma de um arquivo. O arquivo pode conter qualquer tipo de dados: textos, imagens gráficas, vídeo, áudio, ou quaisquer combinações destes tipos de dados. Documento objeto (“document object”): documento (página) na WEB que pode conter qualquer tipo de dados. “WEB site”: é um conjunto de páginas interligadas e conceitualmente relacionadas, usualmente residindo em uma mesma máquina. “Browser”: é um programa que sabe como navegar na WEB, como se comunicar com os servidores e recuperar dados, apresentando-os aos usuários. Servidor: é um “software” que gerencia a informação de um “WEB site”. O servidor atende às solicitações (“requests”) dos “browsers” (clientes).

6 Cliente Cliente Servidor Cliente

7 Arquitetura Cliente-Servidor: a Base da WEB
O cliente e o servidor são programas que se comunicam entre si. O cliente contacta o servidor e solicita uma dada informação. O servidor atende ao pedido (“request”) do cliente. Os “browsers” (ex.: Netscape e Mosaic) são os clientes que contatam os servidores WEB (ex.: CERN e NCSA, Netscape). Efetuam um pedido e depois mostram (“renderizam”) a informação para o usuário. O trabalho do servidor é esperar pelas conexões externas dos clientes, “ouvir” os seus pedidos e atendê-los, quando possível. Para que os servidores e clientes possam se comunicar eles devem observar um protocolo, que estabelece as regras a serem observadas na comunicação

8 Protocolos e Padrões WEB
A WEB não posui um padrão ou protocolo único. Engloba vários padrões e protocolos, de sorte que os usuários podem ter acesso a informações usando qualquer um desses protocolos e/ou padrões. A WEB é basicamente definida por 4 padrões/protocolos: HTTP - Hypertext Transfer Protocol URLs - Uniform Resource Locators HTML - Hypertext Markup Language CGI - Common Gateway Interface Os servidores e clientes da WEB usam estes padrões como mecanismos simples para localizar, ter acesso e mostrar a informação desejada.

9 HTTP - Hypertext Transfer Protocol
É o principal protocolo para a distribuição de informação na WEB. Para entregar a informação solicitada ao cliente, o HTTP define uma transação simples constando de 4 partes: 1) O cliente estabelece uma conexão com o servidor. 2) O cliente submete um pedido ao servidor especificando que deseja recuperar um determinado documento. 3) O servidor envia uma resposta contendo um código de “status” e a representação eletrônica do documento, se disponível. 4) Ou o cliente ou o servidor desconectam.

10 O Intercâmbio da Informação Cliente-Servidor
O cliente se conecta O cliente solicita O servidor responde Fecha-se a conexão

11 Atributos Chaves do Protocolo HTTP (i)
Modelo Cliente-Servidor: objetivando a transferência de dados “hypermedia”. Simplicidade: quando o cliente conecta-se com o servidor, a única informação que o cliente deve enviar é o “request method” e a URL (Universal Resource Locator) - o endereço do recurso na Internet. Flexibilidade e “Content-Typing”: o HTTP possibilita a transmissão de dados de tipos arbitrários. “Content-Typing” identifica o tipo de dado sendo transmitido. “Connectionless”: o HTTP é um protocolo “connectionless”, o que significa que há um limite de um “request” por conexão. Há maior eficiência, pois o servidor não gasta tempo quando não há pedidos a atender e nem gasta recursos para guardar o estado da conexão.

12 Atributos Chaves do Protocolo HTTP (ii)
“Stateless”: o servidor não se lembra de nada referente às solicitações anteriores. Há uma conexão para cada pedido. Vantagem: rapidez, pois o servidor não precisa manter informações sobre o estado do protocolo. Desvantagem: Transmitir mais informações a cada conexão, pois as informações necessárias da transação anterior têm que ser retransmitidas. Meta-informação: possibilita ao servidor prover informação sobre o dado que está sendo enviado. Meta-informação é a informação que nos diz como interpretar os dados. Exemplo: i) o campo “referer”, para identificar o documento que contém o “link” que nos levou ao documento atual; ii) o tamanho do corpo do documento. Pode ser usada para fazer “requests” condicionais e reportar o sucesso de uma transação

13 Categorias de Meta-informação suportadas pelo HTTP
General message header: provê informação não diretamente relacionada ao pedido, resposta, ou objeto sendo transmitido. É usado tanto no pedido (request) como na resposta (response). Request header: qualifica a solicitação (request) em andamento, dizendo ao servidor como interpretá-la. Response header: contém informações relacionadas à resposta do servidor Entity header: estes campos provêm informação sobre o objeto que está sendo retornado. Esta A informação explica como interpretar o objeto sendo submetido.

14 Campos do General Message Header
Date: data e momento no qual a mensagem se originou. Forwarded: usado pelos servidores “proxy” para indicar o caminho percorrido do cliente ao servidor. Usado para diagnósticos em problemas de transmissão. Message-id: contém um número de identificação para cada mensagem. Mime-version: especifica a versão do MIME utilizada na mensagem sendo enviada. Default: MIME v. 1.0

15 Campos do Entity Header (i)
Allow: lista os métodos HTTP padrões que são válidos para uso com o objeto que está sendo transmitido. Content-Length:especifica o tamanho do Entity-Body em bytes. Sem este campo o cliente não saberia quanto deveria ler e nem quando parar. Content-Type: refere-se ao “MIME Internet Type” para o objeto retornado. Pela identificação do tipo do objeto retornado, o cliente pode agir de modo apropriado. Content-Encoding: especifica os mecanismos de compressão, criptografia e empacotamento usados para codificar o objeto Content-Transfer-Encoding: É usado para especificar qualquer mecanismo de codificação usado para transferir dados para o cliente. Valores aceitáveis incluem: 7bit, 8 bit, binary, quoted-printable, e base64. Content-Language: identifica a línguagem natural do objeto.

16 Campos do Entity Header (ii)
Expires: data na qual o dado torna-se não válido. Last-Modified: data e o tempo em que o objeto especificado foi modificado pela última vez. URI: usado para retornar a nova URI para o objeto se o objeto foi movido. Substituiu o campo location. Location: usado para retornar um URI para o objeto que se moveu. Version: número da versão do documento sendo retornado. Derived From: contém o número da versão do documento anteriormente a qualquer modoficação feita pelo “request”. Title: título do objeto. Link: especifica uma ou mais relações de link entre o objeto sendo enviado e outros objetos.

17 Multipurpose Internet Mail Extension - MIME (i)
MIME - definido nos RFCs (“Requests For Comments” 1521 e 1522) É um padrão projetado para suportar a inclusão de objetos com múltiplos tipos em um único objeto. Originalmente concebido para , para possibilitar, p. ex., a anexação de uma figura (ou som ) a uma mensagem. Para tanto o MIME definiu o campo “Content-Type-Header” baseado no padrão previamente definido no RFC 1049. A especificação estabelece que este campo venha antes do real conteúdo da mensagem de , e deve descrever suficientemente o dado contido no corpo da mensagem, de modo que o agente usuário receptor possa selecionar o mecanismo ou agente apropriado para apresentar o dado ao usuário, ou, então, lidar com o dado de forma apropriada.

18 A Sintaxe do MIME Content-Type
type/subtype; parameter; parameter; ... parameter; onde: subtype especifica um tipo de formato particular para o tipo de dado. Exemplos: text/html video/mpeg image/gif audio/basic

19 A Comunicação Cliente-Servidor: Abrindo uma Conexão
Quando um servidor HTTP está executando, ele está ouvindo uma porta (geralmente a porta 80) e esperando pela ocorrência de uma conexão. Tecnicamente falando, o cliente abre um “socket” e associa este “socket” com a porta. Como em UNIX tudo é arquivo, um “socket” é um tipo especial de arquivo que possibilita I/O para a rede. Quando se abre um “socket”, do ponto de vista do cliente está se criando um arquivo virtual. Quando se escreve neste arquivo, na realidade está se enviando dados para a rede

20 A Comunicação Cliente-Servidor: Fazendo um Pedido (“Request”)
Um “request” HTTP 1.0 é um “string” de caracteres com uma ou mais linhas, seguidas por dois “carriage-return line-feeds” (CRLFs). A primeira linha é a linha do pedido. Ela inclui: um método, a URI e o protocolo O restante das linhas são “headers” de vários tipos: general headers, request headers e finalmente os entity headers. Os dois CRLFs sinalizam o fim do pedido”.

21 Formato de um Pedido Completo
Method URI HTTP-Version General-Header Request-Header campos opcionais Entity-Header (meta-informação) ---- linha em branco Entity-Body comprimento determinado pelo Entity-Header 2 CRLFs Exemplo: GET /products/tvset.html HTTP/1.0

22 Métodos (i) Um método descreve a ação que deve ser realizada no recurso especificado. GET: é usado para solicita a um servidor o objeto especificado pela URI. documento ou arquivo programa ou script consulta a base de dados HEAD: é usado para perguntar ao servidor sobre a meta-informação associada ao objeto (às vezes só se quer saber o tamanho do objeto e a data de sua última modificação). Muito útil para testar a validade e acesso aos links.

23 Métodos (ii) POST: é usado quando se precisa transferir dados do cliente para o servidor, a fim de que o servidor possa então, tratá-los. O método POST é usado com freqüencia para submeter o conteúdo de um formulário HTML a um servidor HTTP, que se encarregará de processá-lo. PUT: é usado quando se cria um novo recurso ou se atualiza um recurso já existente. O método PUT submete dados ao servidor, para que fiquem disponíveis via uma URI especificada. Se os dados já existem na URI, eles são usados como uma nova versão. Se os dados não existem , o servidor tenta criar um novo recurso (com os dados) na URI especificada.

24 Métodos (iii) DELETE: diz ao servidor para remover o recurso especificado. LINK: é usado para dizer ao servidor para adicionar relações de links ao objeto especificado na URI. As relações de link podem indicar que um recurso é a continuação de um outro recurso, o predecessor, o pai, etc... UNLINK: remove relações de link do objeto especificado pela URI.

25 Campos do “Request-Headers” (i)
User-Agent: identifica o programa cliente. Em geral é o nome do “browser’. Sintaxe: User-agent: product_list onde, product_list é uma lista de strings na forma product_name ou product_name/product_version. É usado para fins estatísticos. O servidor pode usar este campo para para modoficar a resposta retornada ao cliente. If-Modified-Since: usado, em conjunção com o método GET, para produzir um pedido condicional. O servidor sómente retorna o objeto se ele foi modificado após a data determinada. Se o objeto não foi modificado após a data, o servidor retorna o código de “status” 304.

26 Campos do “Request-Headers” (ii)
Pragma: solicita ao servidor um comportamento determinado. A única opção no HTTP/1.0 é “no-cache”. Este valor especifica aos “caching servers” que recebem o pedido, de que devem realmente pedir o documento, independentemente do mesmo estar “cached”. Authorization: contém a informação de autenticação que é para ser enviada junto com a solicitação. O servidor pode recusar a solicitação se o cliente não possui as permissões apropriadas. Referer: identifica o objeto contendo o link que originou o pedido corrente. . From: endereço de do usuário que está fazendo o pedido

27 Campos do “Request-Headers” (iii)
Accept: especifica um conjunto ou lista de “Content-Types” que o cliente aceitará como resposta Accept-Charset: especifica o conjunto de caracteres que o cliente pode aceitar. Accept-Encoding: especifica uma lista ou conjunto de tipos de codificação de conteúdo (“content-encoding-types”) que o cliente aceitará como resposta Accept-Language: lista de linguagens naturais que o cliente aceitará como resposta.

28 A Comunicação Cliente-Servidor: A Resposta
Uma resposta de um servidor HTTP/1.0 é um string de uma ou mais linhas, seguidas por uma linha em branco e pelo Corpo da Entidade (“Entity-Body”). A primeira linha é a linha de resposta. Ela inclui o protocolo do servidor e o código de “status”. As linhas restantes são “headers” de um ou outro tipo. Primeiro os “General Headers”, depois os “Response Headers” e, finalmente, os “Entity Headers”. Segue-se uma linha em branco separando os headers do objeto.

29 Forma Completa da Resposta
HTTP-Version Status-Code Reason-Phrase General-Header Response-Header campos opcionais Entity-Header (meta-informação) linha em branco --- Entity-Body tem o seu comprimento determinado pelo Entity-Header a linha em branco serve como um delimitador entre os “headers” e o “Entity-Body”. Os campos “General-Headers” usados nas respostas são os mesmos utilizados nos pedidos.

30 Exemplo de Pedido e Resposta Associada
HEAD / HTTP/ pedido HTTP/ OK resposta Date: Monday, 09-Oct-95 22:27:14 GMT Server: NCSA/1.3 MIME-version: 1.0 Content-type: text/html Last-modified: Friday, 29-Sep-95 16:23:46 GMT Content-length: 1774 .

31 1: reservada para uso futuro 2: indica sucesso
Códigos de “Status” Código de “Status”: Indicam se o servidor foi capaz de atender à solicitação com sucesso Categorias dos códigos: 1: reservada para uso futuro 2: indica sucesso 3- indica a ocorrência de redireção 4: indica erro do cliente 5: indica erro do servidor

32 Campos do “Response Header”
Server: identifica o software servidor. Sintaxe: User-agent: product_list onde, product_list é uma lista de strings na forma product_name ou product_name/product_version. WWW-Authenticate: informa ao cliente que a URI solicitada é protegida e é necessária autenticação. Também informa o esquema que está sendo usdo para realizar a autenticação. Retry-After: especifica o espaço de tempo que deve transcorrer, até que o recurso esteja novamente disponível. Public: Possibilita ao servidor especificar uma lista de todos os métodos não-padrões suportados pelo servidor.

33 A Comunicação Cliente-Servidor: O Término da Conexão
Quando ou o cliente ou o servidor desfazem a conexão, o pedido é terminado, independentemente da transação ter sido completada ou bem sucedida.

34 Secure Sockets Layer (SSL)
Evolução do HTTP A realização de negócios via Internet (vendas on-line) depende, basicamente, na segurança das operações comerciais realizadas. Há, portanto, uma forte demanda para mecanismos de autenticação e criptografia. Propostas existentes S-HTTP (Secure HTTP) Shen Secure Sockets Layer (SSL) Uma nova versão do HTTP está sendo definida, chamada HTTP-NG

35 Uniform Resource Locators - URLs (i)
Universal Resource Identifier (URI): esquema de identificação para os recursos da Internet que engloba os URLs e URNs. Uniform Resource Name (URN): esquema para nomear recursos na Internet e que pode ser usado para mapear um nome particular em um ou mais recursos. Uniform (Universal) Resource Locator (URL): uma forma para identificar a localização exata de um recurso na Internet. Referências: RFC URLs RFC URIs RFC URNs

36 Uniform Resource Locators - URLs (ii)
Para descrever um objeto, um nome deve possuir as seguintes características: Persistência: um dado nome deve permanecer válido por tanto tempo quanto necessário. Extensibilidade: a sintaxe de um dado nome deve permanecer válida, em que pese a introdução de novos protocolos . Resolvível: um nome deve possuir informação suficiente para possibilitar o acesso ao documento ou índice a que se refere. Unicidade: Cada objeto deve possuir um nome único. Não-ambígüo: Se dois nomes são idênticos, então referem-se ao mesmo objeto.

37 Uniform Resource Locators - URLs (iii)
Identificar um recurso na Internet requer, não apenas a especificação de sua localização física, mas também o protocolo que deve ser usado para recuperar os dados. O formato de todas as URLs dependem do protocolo usado para se ter acesso ao recurso. Todavia, vários protocolos compartilham um formato comum de URL conhecido como: Common Internet Scheme Sintax (CISS) Formato geral do CISS:

38 Uniform Resource Locators - URLs (iv)
scheme: é o formato, na URL, para um protocolo particular. Em geral os esquemas correspondem aos protocolos usados para se ter acesso aos dados. FTP, HTTP, Gopher, WAIS, Prospero e acesso a arquivos aderem ao CISS. Mailto e News não aderem ao CISS. path: identifica o recurso. URLs que seguem o formato CISS são um subconjunto do formato geral para todas as URLs. O formato geral consiste de: scheme:scheme-specific-string

39 Formato das URLs

40 Exemplos de URLs (i) ftp://ftp.pegasus.br/pub/sumario Atenção! A barra (/) é o nome de um recurso como qualquer outro nome. A maioria dos “sites” usa a barra (/) como o seu recurso de nível mais elevado, ou “home page”. Neste caso, path=/cgi/wandex e searchpart=word=computers. Esta URL faz uma conexão HTTP com na porta 80. Ela solicita ao script CGI Wandex que elabore uma lista dos “sites” relacionados a computadores. Normalmente o texto a ser pesquisado é o resultado da submissão de um formulário a ser preenchido com a palavra a ser pesquisada.

41 Neste caso, o path é: /11/General Information/Train Schedules
Exemplos de URLs (ii) gopher://qwis.circ.gwu.edu:70/11/General%20Information/ Train%20Schedules/Amtrak%20Train%20Schedules Neste caso, o path é: /11/General Information/Train Schedules o recurso: Amtrak Train Schedules Atenção! A inclusão de caracteres especiais em uma URL pode ser feita substituindo-os pela seqüência de escape correspondente.

42 nntp://news.rdc.puc-rio.br/comp.parallel
Exemplos de URLs (iii) news:comp.infosystems. nntp://news.rdc.puc-rio.br/comp.parallel Atenção: A maioria dos servidores NNTP (servidores de NEWS) são configurados para aceitar conexões apenas de uma lista de clientes conhecidos telnet://callsign.cs.buffalo.edu:2000 Atenção: Os outros protocolos identificam recursos. Já o propósito de uma URL telnet é identificar um recurso interativo de uma máquina remota. wais://host:port/database WAIS - Wide Area Information System. Para pesquisar material indexado em uma base de dados.

43 wais://host:port/database?search
Exemplos de URLs (iv) wais://host:port/database?search Search é o critério para a pesquisa na base de dados. wais:// host:port/database/wtype/wpath Wtype é o tipo do objeto; Wpath é o identificador do documento objeto no índice WAIS Prospero: ainda não existem clientes WEB que implementem este esquema diretamente. Todavia o Archie é um cliente Prospero que permite a pesquisa em bancos de dados de objetos Prospero. No formato geral: prospero://host:port/hsoname;field=value Hsoname é o nome do objeto Prospero a ser recuperado; Field e value ajudam a identificar o objeto.

44 URLs Relativas Especificam a localização de um recurso relativamente ao documento em que são referenciadas. URLs relativas ao servidor: especificam o caminho completo do recurso, mas não o protocolo, nome do servidor ou porta. é possível alterar o nome do servidor ou a porta em que ele está escutando sem ter que alterar o texto de quaisquer documentos. URLs relativas ao documento: somente especificam um caminho relativo ao documento em que estão. pode-se mover subsessões do seu “site” para outra máquina ou outra localização dentro do “site” (p. ex.: outro diretório)

45

46 HTTP: A Troca de Informações Cliente-Servidor (i)
[pegasus:~] telnet 80 Trying... Connected to fs2.sp1.lncc.br. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/ OK Date: Monday, 09-Oct-95 22:27:14 GMT Server: NCSA/1.3 MIME-version: 1.0 Content-type: text/html Last-modified: Friday, 29-Sep-95 16:23:46 GMT Content-length: 1774 Connection close

47 HTTP: A Troca de Informações Cliente-Servidor (ii)
[pegasus:~] telnet 80 Trying... Connected to fs2.sp1.lncc.br. Escape character is '^]'. GET / HTTP/1.0 HTTP/ Found Date: Monday, 09-Oct-95 22:29:52 GMT Server: NCSA/1.3 MIME-version: 1.0 Location: Content-type: text/html <HEAD><TITLE>Document moved</TITLE></HEAD> <BODY><H1>Document moved</H1> This document has moved <A HREF=" </BODY> Connection closed.

48 HTTP: A Troca de Informações Cliente-Servidor (iii-a)
[pegasus:~] telnet 80 Trying... Connected to Escape character is '^]'. GET / HTTP/1.0 HTTP/ Document follows Date: Sat, 14 Oct :40:16 GMT Server: NCSA/1.4.2 Content-type: text/html <!doctype html public "-//IETF//DTD HTML 2.0//EN"> <HTML> <HEAD> <TITLE>The IBM world wide web home page</TITLE> <META NAME="KEYWORDS" CONTENT="homepage home page index ibm international business machines"> <META NAME="OWNER" <META NAME="ABSTRACT" CONTENT="The IBM Corporate Home Page"> <META NAME="CC" CONTENT="int"> <META NAME="LANGUAGE" CONTENT="en.us"> <!-- This home page customized for on Sat, 14 Oct :40:17 --> </HEAD>

49 HTTP: A Troca de Informações Cliente-Servidor (iii-b)
<BODY> <H1><IMG WIDTH=480 HEIGHT=100 ALT="IBM October" SRC="/images/mastheads/homepage. gif"></H1> <BR> <A HREF="/Newsfeed/" TITLE="Newsfeed"><IMG SRC="/images/icons/newsfeed.gif" BORDER=0 ALT="Newsfeed" WIDTH=75 HEIGHT=88></A> <A HREF="/Stretch/" TITLE="Stretch"><IMG SRC="/images/icons/stretch.gif" BORDER=0 ALT="Stretch" <A HREF="/Products/" TITLE="What we offer"><IMG SRC="/images/icons/products.gif" BORDER=0 ALT="What we offer" <a href=" | <a href=" ] </b> </body> </html> Connection closed. [pegasus:~]

50 Hypertext Markup Language - HTML (i)
HTML é o mecanismo usado para apresentar os documentos (páginas) na WEB e definir as características relativas à sua aparência. Princípios: Linguagem comum usada para agregar (alinhavar) informações de diferentes fontes Simples, tanto para os autores de documentos HTML como para programadores Acomodar as mudanças tecnológicas e sociais no uso da WEB Prover visualização independente da plataforma usada

51 Hypertext Markup Language - HTML (ii)
“Markup Languages”: são usadas para descrever o “lay-out” (apresentação) dos documentos. “Tags” ou marcas especiais são inseridas dentro do texto original, indicando como o mesmo deverá ser apresentado. O HTML é definido em termos da “Standard Generalized Markup Language”, um padrão ISO utilizado para definir linguagens de “markup”.

52 “Standard Generalized Markup Language” (i)
Níveis de informação existentes em qualquer comunicação: conteúdo ex.: frase, discurso ... sobre o conteúdo (“markup”) ex.: sorriso, postura irônica, etc... A SGML não é um conjunto de códigos padrões: ex.: indicativos de fonte maior, negrito, novo parágrafo, etc. i) O número de códigos necessários teóricamente estaria em aberto (existem muitos tipos de documentos com diversos elementos de “markup”); ii) não haveria como tratar os eventuais erros

53 “Standard Generalized Markup Language” (ii)
SGML é uma meta-linguagem, isto é, um meio de descrever formalmente uma linguagem, no caso as linguagens de markup SGML é uma linguagem usada para criar a definição de um tipo de documento (“document type definition”- DTD) que define precisamente os elementos e outras construções necessárias para um documento ou para um grupo de documentos estruturados de forma semelhante. A definição dos elementos (declaração dos elementos) tem duas funções críticas: indicar o nome oficial do elemento, que aparecerá entre delimitadores como uma “tag”(ex.: <capítulo>); descrever o que cada elemento pode conter (“content model”).

54 “Standard Generalized Markup Language” - Exemplo
Sintaxe, em SGML, para definir o capítulo de um livro simples e sem figuras: <ELEMENT capítulo (capítulo, (parágrafo | cabeçalho)+ ) <ELEMENT (capítulo | parágrafo | cabeçalho) (#PCDATA) símbolo significado uma ou mais vezes | ou , seguido de (...) indica grupamento PCDATA indica que os elementos assim definidos não possuem sub-elementos; eles contêm apenas os caracteres que constituem o conteúdo do documento (“parsed character data”)

55 “Standard Generalized Markup Language” (iii)
O HTML é definido de forma semelhante! Todo documento HTML possui três partes: i) Uma declaração SGML que associa quantidades de processamento e nomes de “tokens” de sintaxe a valores específicos. Esta declaração informa ao sistema receptor exatamente qual o conjunto de caracteres, delimitadores e “features” opcionais SGML estão sendo usadas. Ex.: a declaração SGML no HTML DTD especifica que o “string” que abre uma “tag” é </ e o comprimento máximo de um nome é 40 caracteres.

56 “Standard Generalized Markup Language” (iv)
ii) Um prólogo, incluindo uma ou mais declarações de tipos de documentos, relações de elementos e atributos, e referências que podem ser representadas por “markup”. Esta parte, conhecida como Document Type Definition, diz exatamente a um sistema que markups deve esperar. Ex.: A HTML DTD especifica que o elemento HEAD contém, no máximo, um elemento TITLE. iii) Uma instância, que contém os dados e os “markup” do documento. Ex.: o “source” de uma “home page” particular escrito em HTML.

57 Hypertext Markup Language - HTML (iii)
Importante: Todos os documentos HTML compartilham a mesma declaração SGML e o mesmo prólogo. Assim, nas implementações WEB em geral somente se transmite e armazena a parte correspondente à instância do documento HTML. HTML padrão HTML “internal draft” HTML “internal draft”

58 Hypertext Markup Language - HTML (iv)
Um elemento em HTML é um identificador para certas partes de um objeto, incluindo como a parte do objeto é “renderizada” (apresentada), como o objeto é “linkado” (associado) a diferentes objetos, etc... Os elementos HTML possuem tres partes: “tag” inicial: indica o início do elemento;entre os delimitadores (<) e (>) tem-se o nome do elemento seguido pelos atributos correspondentes. O conteúdo: tudo o que aparece entre as “tags” inicial e final de um elemento é definido pelo elemento (“marked up”). O conteúdo de um elemento pode ser constituído por texto e outros elementos HTML. “tag” final: sinaliza o término do elemento. Seus delimitadores são (</) e (>).