Jornada de Atualização em Informática
Recife PE
Agosto de 1996
Padrões para troca de documentos Hipermídia
Eduardo Simões de Albuquerque
Padrões para troca de documentos hipermídia
1. INTRODUÇÃO
4
2. INFORMAÇÃO DE CONTEÚDO E DE APRESENTAÇÃO
4
2.1 Linguagens de Markup
5
3. PADRÕES RELACIONADOS A MULTIMÍDIA
6
3.1 O modelo de referência Dexter
3.1.1 Problemas com o modelo
7
8
3.2 O formato de troca de multimídia CWI (CMIF)
8
3.3 O Modelo Hipermídia de Amsterdã (The Amsterdam Hypermedia Model AHM)
3.3.1 Sincronização no AHM
3.3.2 Contexto de Ligações (link context)
3.3.3 Canais
3.3.4 Limitações do AHM
10
11
12
12
13
3.4 O formato QuickTime
3.4.1 Limitações de QuickTime
13
14
3.5 Office Document Architecture (ODA)
3.5.1 Troca de Documentos ODA
3.5.2 Extensões a ODA
14
16
16
3.6 SGML
3.6.1 Um documento SGML
3.6.2 Troca de documentos SGML
3.6.3 SGML binário (SGML-B)
3.6.4 Limitações de SGML
16
17
19
19
19
3.7 HyTime
3.7.1 A máquina HyTime (HyTime engine)
3.7.2 Troca de documentos HyTime
3.7.3 A Linguagem de Descrição de Música Padrão (Standard Music Description Language
SGML)
3.7.4 Comentários finais
20
22
23
3.8 Adobe Acrobat
3.8.1 Limitações do Acrobat
25
26
3.9 A World Wide Web
27
3.10 Localizadores Uniformes de Recursos (Uniform Resource Locator - URL)
28
3.11 Números Universais de Recursos (Universal Resource Numbers - URN)
28
3.12 A Linguagem de Markup de Hipertexto (Hypertext Markup Language HTML )
3.12.1 HTML+
29
30
3.13 O Ambiente de Apresentação para Objetos Multimídia (Presentation Environment for
Multimedia Objects PREMO)
30
Página 48
23
25
Padrões para troca de documentos hipermídia
3.14 Considerações finais
30
4. MHEG
31
4.1 Objetivos do projeto
4.1.1 Adequação de MHEG
32
32
4.2 Escopo de MHEG
33
4.3 Estrutura de MHEG
34
4.4 Evolução de MHEG
35
4.5 Nível de abstração em MHEG
38
4.6 As classes de MHEG
4.6.1 A classe Mh-Object
4.6.2 A classe Action
4.6.3 A classe Link
4.6.4 A classe Model
4.6.5 A classe Script
4.6.6 A classe Descriptor
4.6.7 A classe Component
4.6.8 A classe Content
4.6.9 A classe Multiplexed Content
4.6.10 A classe Composite
4.6.11 A classe Container
4.6.12 Comentários finais
39
39
39
40
41
41
42
42
42
43
43
43
44
4.7 MHEG-5
4.7.1 Estrutura de MHEG 5
4.7.2 Relacionamento de MHEG 5 com MHEG 1
44
44
47
4.8 MHEG vs HyTime vs PREMO
48
5. REFERÊNCIAS
ERRO! INDICADOR NÃO DEFINIDO.
Página 48
Padrões para troca de documentos hipermídia
Lista de Figuras
Figura 1 Exemplo de Markup procedimental...............................................................5
Figura 2 Exemplo de markup lógico ...........................................................................6
Figura 3 O modelo Dexter ..........................................................................................8
Figura 4 Componentes Estruturais de Documentos CMIF......................................... 10
Figura 5 O Modelo Hipermídia de Amsterdam (componente atômico (e) e composto
(d)) ................................................................................................................... 11
Figura 6 Relações temporais no AHM ...................................................................... 12
Figura 7 Componentes de QuickTime ....................................................................... 13
Figura 8 Estruturas Lógicas e de Layout em ODA .................................................... 15
Figura 9 Exemplo de uma Definição de Tipo de Documento (DTD) ......................... 18
Figura 10 Exemplo de uma instância de um documento do tipo carta (definido na..... 19
Figura 11 Módulos de HyTime ................................................................................. 22
Figura 12 Domínio de descrição em SMDL .............................................................. 23
Figura 13 Estrutura do Cantus em SMDL................................................................. 24
Figura 14 Exemplo de uma tela do Acrobat .............................................................. 27
Figura 15 Exemplo de uma URL............................................................................... 28
Figura 16 Exemplo de um documento HTML........................................................... 29
Figura 17 Escopo de MHEG .................................................................................... 33
Figura 18 Hierarquia de Classes de MHEG............................................................... 34
Figura 19 Hierarquia de classes MHEG em 1991 ...................................................... 36
Figura 20 Hierarquia de classes MHEG em 92 (e) e atual (d) .................................... 37
Figura 21 Estrutura de um objeto Link...................................................................... 41
Figura 22 Diagrama do topo da hierarquia de classes de MHEG 5 ............................ 45
Figura 23 Hierarquia das subclasses de Ingrediente ................................................... 46
Figura 24 Estrutura das subclasses de Presentable .................................................... 46
Figura 25 Diagrama das subclasses da classe Visível (Visible) ................................... 47
Figura 26 Relacionamento entre MHEG 5 e MHEG 1 .............................................. 48
Figura 27 Relacionamento entre HyTime, MHEG e PREMOErro! Indicador não definido.
Página 48
Padrões para troca de documentos hipermídia
1. Introdução
A indústria da computação tem sido guiada mais pela tecnologia do que pelos
requisitos de seu mercado. Ao contrário de mercados como os de aparelhos de sons onde
todo produto reproduz os mesmos tipos de fitas ou CDs, e toda diferenciação de produto
é em termos de preço, performance e funcionalidade, até recentemente os sistemas de
computação eram proprietários: um produto escrito para um sistema não funcionava em
outro sistema.
A compatibilidade era tanto nos níveis de software como de hardware. No entanto,
o alto custo de se produzir sistemas de computação, e a necessidade de se fazer aplicações
disponíveis em uma larga gama de máquinas levou a indústria a definir padrões apesar do
custo relativo em termos de performance.
Multimídia, como uma das mais recentes aplicações de computação (e também
uma das mais caras e exigentes), é uma das áreas que mais tem sofrido com este problema.
É abertamente reconhecido que a menos que padrões para troca de informação multimídia
sejam definidos e utilizados em larga escala, a indústria não atingirá um grau de
amadurecimento.
A indústria tem nos últimos tempos acompanhado o desenvolvimento de padrões
para compressão de mídia tais como JPEG e MPEG. A adoção geral destes padrões fez
com que se tornasse possível a implementação de alguns desses algoritmos em hardware a
um custo razoável para computadores pessoais, levando a uma redução significativa nos
custos de comunicação e armazenamento de dados multimídia. A performance hoje obtida
em computadores pessoais também está permitindo o desenvolvimento de sofisticadas
aplicações multimídia para um computador doméstico padrão. Na verdade, o mercado
doméstico é hoje o mercado mais importante para a produção de produtos multimídia.
Este texto apresenta e discute alguns dos problemas relacionados à troca de
Documentos Multimídia e também os padrões em desenvolvimento. Uma grande ênfase
será dada ao trabalho desenvolvido pelo grupo Multimedia and Hypermedia information
coding Expert Group (MHEG) que se tornou recentemente um Padrão Internacional da
ISO.
2. Informação de conteúdo e de apresentação
A maioria dos dados que recebemos carregam informação em dois níveis:
1. Conteúdo: o dado abstrato sendo transmitido e,
2. Apresentação: a forma na qual a informação é apresentada e percebida.
Página 48
Padrões para troca de documentos hipermídia
O mesmo conteúdo pode ser apresentado em um formato completamente diferente
dependendo do contexto. Por exemplo, uma fala pode ser escrita para uma audiência com
problemas de audição ou ser falado para outra audiência. Em cada caso, embora o
conteúdo seja o mesmo, a informação de apresentação é muito diferente. Para
portabilidade, é desejável que informação de conteúdo e de apresentação sejam mantidos
em estruturas diferentes. Quando as informações de conteúdo e de formatação são
mantidos separadamente, é fácil alterar a forma como a informação é apresentada como
discutiremos nas próximas seções.
Infelizmente computadores, como seres humanos, normalmente não compartilham
a mesma língua. Um dos padrões mais largamente aceitos é o definido pelo padrão da ISO
646 que define a versão de referência internacional do conjunto de caracteres ASCII. O
padrão ASCII é codificado em 7 bits e é suficiente para representar inglês corretamente.
Outras línguas modernas, incluindo diversas línguas européias, requerem um sistema de 8
bits. É óbvio que um sistema tal como ASCII, incapaz até mesmo de representar diversas
línguas atuais, não é suficientemente poderoso para representar todo o espectro que
abrange os documentos multimídia.
Como ASCII é usado por virtualmente todos os sistemas de computadores, ele é
uma boa forma de se trocar informação entre computadores. Um método usado para
sobrepor as limitações impostas por um conjunto pequeno de caracteres é adicionar
“marcas” (tags) dentro da informação textual. Estas marcas representam como o conteúdo
deve ser apresentado, em oposição a diretamente representar o formato de apresentação.
Uma forma comum de se usar marcas é pela definição de linguagens de markup tais como
SGML.
2.1 Linguagens de Markup
{\size{12pt} 1. Linguagens de Markup}
\size{10pt}
Aqui está o primeiro parágrafo desta seção.
E aqui está o segundo parágrafo
{\size{12pt} 2. Padrões}
\size{10pt}
Aqui está o primeiro parágrafo da seção padrões e com uma
referência à seção 1
Figura 1 Exemplo de Markup procedimental
Markup é alguma informação que é adicionada a um documento para descrever
sua estrutura ou instruções de formatação. Por exemplo, o texto na Figura 2 contém
informações (usando uma notação similar a LaTeX) sobre como ele deve ser formatado.
O markup descreve as instruções de como formatar as duas seções de um documento de
uma forma muito rígida. Se o usuário decide alterar as seções em um documento, a
numeração de seções terá que ser refeita manualmente. Se ele quiser mudar o tamanho dos
fontes usados para o corpo do texto e para o título das seções, todo o documento terá que
Página 48
Padrões para troca de documentos hipermídia
ser editado, e o mesmo se aplica ao espacejamento entre as seções e parágrafos. Neste
caso, o markup está proporcionando instruções de formatação mas nenhuma informação
sobre a estrutura.
Uma maneira mais flexível de descrever o mesmo texto é dado na Figura 2,
também usando uma notação similar a LaTeX. A figura mostra o conteúdo e a estrutura
de seções que poderiam ser parte de um livro, ou artigo, etc. Na figura, o markup é
definido por um palavra chave prefixada por \ e o conteúdo marcado esta envolvido por
{} (por exemplo, os títulos nas seções) ou simplesmente colocados entre dois marcadores
como o conteúdo de cada seção que colocado entre as instruções de markup de seção
\section{}. Não há marcas para indicar o começo e fim de parágrafos que são
delimitados por uma linha em branco. A marca \label{s_markup} fornece
informação que pode ser usada para referências cruzadas ou mecanismos de indexação
para recuperar a posição deste trecho de texto dentro da estrutura geral.
\section{Linguagens de Markup}
\label{ling_markup}
Aqui está o primeiro parágrafo desta seção.
E aqui
está o segundo parágrafo
\section{Padrões}
Aqui está o primeiro parágrafo da seção padrões e com uma
referência à seção~\ref{ling_markup}
Figura 2 Exemplo de markup lógico
Como as seções serão definitivamente formatadas não é definido pelo markup, que
define apenas estruturas lógicas. Funções de processamento aplicadas sobre os
componentes lógicos para a produção do layout final podem ser muito diferentes se as
seções forem partes de um livro ou de um artigo em duas colunas.
O conceito de markup lógico pode ser estendido para estruturas mais abstratas
alem das de formatação, proporcionando ganchos para processamento posterior. Por
exemplo, um componente lógico poderia especificar o preço que pode vir a ser usado para
alguma computação; ou uma referência tal como na Figura 2 ou mesmo para gerar
referências cruzadas dentro de um texto ou tabela de conteúdo.
3. Padrões relacionados a multimídia
Esta seção apresentará as principais tentativas de criação de padrões para a
representação e troca de documentos multi/hiper-mídia. O desenvolvimento de tais
padrões começa com a definição de modelo de referência Dexter (descrito na próxima
seção) cujo escopo era limitado aos sistemas de hipertexto existente quando da sua
definição. O texto apresenta alguns modelos originados na indústria que por seu uso em
Página 48
Padrões para troca de documentos hipermídia
larga escala tornaram-se padrões “de facto” e também outros padrões “de jure”
desenvolvidos e em desenvolvimento por comitês internacionais.
3.1 O modelo de referência Dexter
Modelo de Referência Dexter [Halasz e Schwartz, 1990][Schwartz, 1994]
representa uma tentativa de unificar as abstrações encontradas em vários sistemas de
hipertexto e é também uma base para o desenvolvimento de padrões para a troca de
documentos entre sistemas de hipertexto.
O modelo é o resultado de dois workshops sobre hipertexto. O primeiro deles
aconteceu na Dexter Inn em New Hampshire (Estados Unidos), de onde o seu nome se
origina.
O modelo Dexter divide um sistema de hipertexto em três camadas (Figura 3):
• Camada de tempo e execução: esta camada proporciona a funcionalidade para o
uso, visualização e manipulação do rede de hipertexto. O modelo Dexter define
apenas um modelo básico e não cobre interação com o usuário. Isto é devido ao fato
das ferramentas que implementam estas facilidades serem muito variadas. A
principal função da camada de tempo de execução é a apresentação (criação de
instâncias) de um componente para o usuário. Quando uma instância do componente
é criada, uma cópia é efetuada e todas as operações do usuário são realizadas sobre
esta cópia, que é posteriormente armazenada pela camada de armazenamento
É possível haver mais de uma instância do mesmo componente e manter controle
sobre estas instâncias; a camada de tempo de execução cria uma sessão que mantém
um mapeamento entre instâncias e componentes.
• Camada de armazenamento: é a camada de foco do modelo. A camada de
armazenamento descreve a base de dados compostas de uma hierarquia de
componentes inter-conectados por ligações de referência. Componentes são tratados
como dados genéricos de armazenamento não se fazendo distinção em relação a
mídia usado pelo componente.
• Camada interna aos componentes: componentes no modelo correspondem a nós em
hipertexto. Esta camada lida com o conteúdo e a estrutura interna dos componentes
dentre de uma rede de hipertexto. Como componentes podem conter uma gama
ilimitada de conteúdos e estruturas, o modelo não cobre esta parte. Modelos para
aplicações específicas tais como ODA e SGML devem ser usadas para completar a
definição de um hipertexto como um todo.
A interface entre a camada interna aos componentes e a camada de
armazenamento é chamada ancoragem. Ela proporciona os meios para endereçar itens
dentro de um componente.
A interface entre as camadas de tempo de execução e de armazenamento é
chamada especificação de apresentação e é um mecanismo que armazena informações
sobre como um componente deve ser apresentado ao usuário.
Página 48
Padrões para troca de documentos hipermídia
Camada de tempo de Execução
Apresentação do hipertexto;
interação com usuário;dinâmica
Especificações de Apresentação
Camada de Armazenamento
rede de nós e ligações
um banco de dados contendo uma
Foco do modelo
Dexter
Ancoragem
Camada interna aos componentes
o conteúdo/estrutura dentro
dos nós
Figura 3 O modelo Dexter
3.1.1 Problemas com o modelo
Dexter representa uma das primeiras tentativas de padronizar os sistemas de
hipertexto a embora seja relativamente recente, ele não deu a atenção necessária a alguns
do problemas que hipermídia adiciona a hipertexto dentre os quais:
• Dexter não tem noção de tempo o que o faz inadequado para expressar hipermídia
em geral;
• Dexter não permite ligações entre hipertextos e não faz distinção entre conteúdos
que são administrados dentro do escopo do sistema e aqueles manejados por
aplicações de terceiros;
• Objetos compostos também são limitados como discutido em [Leggett e Schnase,
1994], em particular no que se refere a composição, que é por cópia e não por
referência o que impede o reuso de objetos de conteúdo.
3.2 O formato de troca de multimídia CWI (CMIF)
O Formato de Troca de Multimídia CWI (CMIF) [Bulterman et al., 1991] é usado
para descrever as relações temporais e estruturais existentes em documentos multimídia.
O projeto CMIF tinha dois objetivos:
1. Definir uma estrutura que separasse os aspectos temporais, espaciais e de conteúdo
de documentos multimídia;
Página 48
Padrões para troca de documentos hipermídia
2. Investigar meios de usar a descrição de documentos ao invés de seu conteúdo como
meios de interrogação e sincronização de um ou mais conjuntos de documentos.
Tendo em vista os objetivos acima, projeto enfoca três problemas gerais existentes em
aplicações multimídia:
• Elementos manipulados dentro de sistemas de multimídia em geral consistem em
dados brutos em oposição a informação estruturada, com pouco significado
inerente;
• A representação e manipulação de tais dados é altamente dependente de máquina
e/ou dispositivo;
• A sincronização entre aplicações multimídia é com freqüência implicitamente
codificada como uma função da velocidade de um sistema e interface particular,
limitando as formas como interações entre elementos podem ser expressas e
implementadas.
Um documento CMIF é formado por uma coleção de diversas mídias e um
conjunto de relações de sincronização de estrutura descrevendo como manipular e
apresentar estes componentes (Figura 4).
CMIF fornece uma infra-estrutura poderosa para a construção de aplicações
hipermídia, em particular quando expressando relações de tempo de sincronização. No
entanto, o modelo não fornece uma forma direta para a representação de “hipermídia”
pois não possui um mecanismos para representar hiperlinks.
Página 48
Padrões para troca de documentos hipermídia
Tempo
arcos de
sincronização
dj jdhjdfha sdfd alkdjfasdf
sddjfasidf ai iais fadi il
sdfasdfs jkdhfljdfj
Canal Descritores de eventos
Figura 4 Componentes Estruturais de Documentos CMIF
3.3 O Modelo Hipermídia de Amsterdã (The Amsterdam Hypermedia
Model AHM)
O Modelo Hipermídia de Amsterdã [Hardman et al., 1993] [Hardman et al., 1994]
é um arcabouço que pode ser usado para descrever sistemas de hipermídia. O AHM
estende o modelo de hipertexto Dexter (descrito na seção 3.1) através da adição de
noções de tempo como definido pelo CMIF (visto na seção anterior).
O AHM agrupa relacionamentos entre itens de dados em dois grupos
1. Coleção: a classe de itens relacionados com a identificação de componentes que
devem ser apresentados em conjunto;
2. Sincronização: a classe de itens que especifica o ordenamento relativo no qual
os componentes deve ser apresentados.
Os grupos anteriores contrastam com o modelo Dexter que provê suporte para
coleções através da definição hierárquica de componentes. O conjunto de componentes
atômicos pode ser modelado por compostos Dexter. No entanto, Dexter não oferece
mecanismos para a especificação de relações temporais entre componentes.
O AHM separa o conteúdo de dados e a informação de apresentação através da
definição de componentes atômicos e compostos conforme mostrado na Figura 5
Página 48
Padrões para troca de documentos hipermídia
Nome do canal
Especificações de
Apresentação
Duração - Especificada ou implicita
Especificação de
Apresentação
Arcos de sincronização
Informação semântica
ID. componente origem
ID componente destino
Relação de tempo
outros comp. - inf. especificas de
apresentação
Atributos
Info. apres. específica do
componente
Atributos
Informação semântica
ID. da âncora
âncoras
Valor
âncoras
Conteudo
ID. da âncora
lista de (id. comp, ID âncora)
Ponteiro para dados ou bloco de
dados
Tipo do composto
Filhos
escolha ou paralelo
Id. do commponente
Hora de início
Figura 5 O Modelo Hipermídia de Amsterdam (componente atômico (e) e composto
(d))
Os componentes atômicos contêm informação relativa a um bloco de dados
específico incluindo duração, especificações de apresentação e identificação de âncoras
enquanto que um composto contém informação de apresentação relacionada com uma
coleção de blocos atômicos e compostos. Um composto não contém dados (conteúdo);
tais dados dever ser ou incluídos ou referidos em um componente atômico.
Existem dois tipos de compostos:
1. Composto de Escolha: no máximo um filho é mostrado;
2. Composto Paralelo: todos componentes são mostrados.
3.3.1 Sincronização no AHM
O AHM suporta dois níveis de sincronização conforme mostrado na Figura 6
Página 48
Padrões para troca de documentos hipermídia
a
b
c
offset do começo
âncora
referência
arco de sincronização
Figura 6 Relações temporais no AHM
1. Sincronização de granulosidade grossa (coarse-grained synchronisation): define as
restrições entre os filhos em um composto tais como tempo de começo relativo de
cada filho no composto. Esta informação deve ser dada explicitamente com a
definição do filho;
2. Sincronização de granulosidade fina (fine-grained synchronisation): define
restrições entre filhos (que podem ser aninhados) dentro de um componente de um
composto. Estas restrições são definidas usando-se arcos de sincronização.
3.3.2 Contexto de Ligações (link context)
O AHM define o conceito de um contexto de ligação para especificar como os
componentes se comportam quando uma referência (link) é seguida. Um contexto de
ligação é um composto que contem uma coleção de componentes afetados pela ativação
da referência. Um contexto fonte (source context) para uma referência é a parte da
apresentação afetada pelo início de uma referência e o contexto de destino (destination
context) é a parte afetada pela chegada de uma referência.
3.3.3 Canais
Os canais permitem a especificação dos atributos globais de saída de documentos.
Um canal pode especificar, por exemplo, o fonte e o estilo para um canal de texto.
O conceito de canal também pode ser usado para especificar, por exemplo, a
língua a ser usada para a saída de uma fala ou texto em um documento com mais de uma
língua.
Página 48
Padrões para troca de documentos hipermídia
3.3.4 Limitações do AHM
A principal limitação atual do AHM é derivada do fato que o modelo tomado
como base (CMIF) não suportar âncoras compostas e consequentemente não é possível a
definição de condições complexas para as ligações.
3.4 O formato QuickTime
O formato QuickTime Movie File (QMF) [Apple, 1993] foi originalmente
desenvolvido pela Apple para os Macintoshes, como uma extensão ao sistema operacional
System 7. Atualmente, Quicktime está disponível para outras plataformas.
O QMF funciona como um invólucro para dados baseados em tempo. Ele
apresenta um modelo para armazenamento e troca de mídia relacionada com tempo que é
independente das capacidades de sincronização e temporização internas dos sistemas que
o utilizam.
Um “filme” em QuickTime é na verdade qualquer dado dinâmico como um filme
propriamente dito, uma apresentação de slides, ou uma animação. Um filme pode ter
diversas trilhas com tipos diferentes de informação mas só pode haver uma trilha com uma
mídia específica (como audio, por exemplo). Um átomo de filme é composto de átomos
de trilhas que são descritos na Figura 7 (de [Buford, 1994]).
Filme com diversas
trilhas
trilha com átomos de mídia
Mapeamento de átomos
de mídia para mídia
física
Figura 7 Componentes de QuickTime
Um filme também pode incluir especificações para um pôster que é uma imagem
única para representar um filme (um ícone por exemplo) e um preview que é um pequeno
segmento de um filme também usado para identificar este.
Página 48
Padrões para troca de documentos hipermídia
Um sistema completo de QuickTime inclui componentes para a autoria, edição e
visualização de filmes; um administrador de compressão que permite o uso de algoritmos
adequados para cada mídia; e mecanismos para armazenar temporariamente filmes que
serão incluídos em outros documentos.
3.4.1 Limitações de QuickTime
Embora QuickTime tenha sido desenvolvido para adicionar mídia baseada em
tempo a aplicações já existentes, ele não permite que links sejam disparados de dentro dos
componentes por ele controlados.
3.5 Office Document Architecture (ODA)
O Office Document Architecture (ODA) [ISO, 1989] [Brown, 1989] é um padrão
para troca e armazenamento de documentos. ODA define um modelo de documento
hierárquico e orientado a objetos. Um documento em ODA pode ser visto como uma
árvore na qual as folhas contém o conteúdo e a forma define a estrutura do documento. A
separação da estrutura e do conteúdo facilita a administração e criação de documentos
multimídia. Um atributo de objeto é uma propriedade do documento ou de um
componente do documento. O atributo representa uma característica de um documento ou
uma relação entre este e outros documentos.
Um documento ODA é descrito por duas estruturas:
1. Estrutura lógica: a estrutura lógica do documento é baseada em seu
significado, ou seja, a estrutura que faz sentido para o autor e leitor do
documento. A estrutura lógica define o relacionamento entre componentes
lógicos e componentes de conteúdo. Exemplos de componentes lógicos são:
capítulos, seções, figuras, etc. Componentes lógicos podem também especificar
itens especializados tais como entradas de dicionário.
2. Estrutura de layout: a estrutura de layout define a aparência do documento,
como ele deve ser formatado. Exemplos de objetos de layout são páginas,
molduras (áreas retangulares) e blocos.
ODA também define o conceito de classes de documentos que são análogas a
DTDs em SGML. Uma classe de documentos é definida por estruturas genéricas. Baseado
no conceito de classes de documentos, as estruturas acima podem ainda ser dividas em:
• Estruturas genéricas (de layout e lógicas): que são associadas a classes de
documentos, e
• Estruturas específicas (de layout e lógicas): que são associadas com exemplo da
classe.
A separação das estruturas lógicas e de layout em ODA pode ser vista na Figura 1.
Os objetos nas folhas contém um atributo que define o tipo do conteúdo associado. Cada
tipo de conteúdo é manipulado diferentemente por regras denominadas arquiteturas de
conteúdo. Atualmente, ODA define três tipos de arquiteturas de conteúdo:
Página 48
Padrões para troca de documentos hipermídia
1. Arquitetura de conteúdo de caracter: é composta de caracteres de controle e
gráficos. O formato de posicionamento dos caracteres são controlados com um
conjunto de atributos e características. Por “default”, os caracteres são definidos
verticalmente, em linhas a partir do topo do bloco e progredindo da esquerda para a
direita e de cima para baixo. É possível alterar atributos tais como direção de
progressão de linha e caracteres, produzir super e subscritos, etc.
2. Arquitetura de conteúdo de Raster graphics: o conteúdo de raster graphics
representa uma imagem bi-dimensional formada por um arranjo também bidimensional de elementos de imagem (PEL, Picture ELements). Diversos atributos
podem ser alterados, incluindo: direção de progressão dos PELs dentro de uma
linha, direção de progressão das linhas, ponto de início a partir do qual os PELs são
colocados dentro de uma linha, tamanho da imagem, etc.
3. Arquitetura de conteúdo graficos geométricos: esta arquitetura é baseada no padrão
CGM (Computer Graphics Metafile). Atributos de ODA são usados para prover
valores iniciais de CGM tais como tipo de linha, largura e cor, tamanho da imagem
final, etc.
Cada uma das arquiteturas acima define uma ou mais classes similares a classes de
documentos. Estas classes, por sua vez, podem conter outras classes oferecendo diferentes
níveis de facilidades como, por exemplo, para alterar a direção na qual os caracteres são
posicionados em um documento.
Seção
Estrutura
Lógica
Estrutura de
Layout
Subtítulo
Parágrafo
Parágrafo
Conteúdo
Conteúdo
Conteúdo
Bloco
Bloco
Bloco
Moldura
Página
Figura 8 Estruturas Lógicas e de Layout em ODA
Página 48
Padrões para troca de documentos hipermídia
3.5.1 Troca de Documentos ODA
Os documentos ODA podem ser trocados em diferentes formatos:
• Formato ODIF: ODIF é uma sintaxe abstrata onde os componentes e atributos
de um documento são representados por uma hierarquia de estruturas de dados
que aparecem em uma determinada ordem.
• Formato Office Documento Language (ODL): que é um uso particular de
SGML para representar documentos ODA.
3.5.2 Extensões a ODA
Diversas extensões a ODA tem sido propostas para incorporar multimídia. Estas
extensões incluem:
• Novas características de arquiteturas de conteúdo que: permitem a inclusão de
mensagens de voz e outras formas de audio a documentos ODA; permitem a
inclusão de objetos CCITT H.261, JPEG, MPEG-1 e MPEG-2; adicionam atributos
a documentos para permitir o controle de como imagens devem ser apresentadas,
tais como controle de contraste, brilho e saturação; permitem a definição de marcas
dentro de um vídeo clipe; permitem que seqüências de vídeo sejam cortadas tanto no
espaço como no tempo para, por exemplo, mostrar apenas partes de um vídeo clipe.
• HyperODA: As extensões de multimídia para ODA (conhecidas como HyperODA)
tem como objetivo a inclusão de informação audiovisual a ODA. As principais
características de HyperODA são que ela: suporta referências a dados mantidos
externamente aos documentos; suporta estruturas não lineares, usando hiperlinks
contextuais e independentes baseados no modelo HyTime; suporta relacionamentos
temporais entre componentes de documentos (por exemplo, seqüencial, paralelo,
cíclico, duração, atraso para começo).
HyperODA ainda não se tornou um Padrão Internacional.
3.6 SGML
A Standard Generalised Markup Language (SGML) [ ISO, 1986a, Goldfarb,
1990] é o padrão 8879 da ISO. Ele é baseado em dois postulados:
1. “O markup deve descrever a estrutura do documento e outros
atributos e não especificar o processamento realizado sobre ele.
Assim, o markup descritivo precisa ser realizado apenas uma vez
e será suficiente para todo processamento futuro.”
2. “O markup deve ser rigoroso de tal forma que as técnicas
disponíveis para o processamento de objetos rigorosamente
Página 48
Padrões para troca de documentos hipermídia
definidos tais como programas e bases de dados podem ser
usados para o processamento de documentos também.”
O padrão também é independente de sistemas e de dispositivos no sentido que ele
lida com armazenamento virtual o qual pode ser mapeado sobre diferentes dispositivos
físicos de armazenamento oferecidos por diversos fabricantes. Ele é independente de
linguagem pois pode ser usado mesmo em linguagens que não usam alfabetos baseados em
Latim como por exemplo Grego. É independente de aplicação pois é suficientemente
flexível para codificar tanto documentos simples como complexos, e é capaz de lidar com
documentos sujeitos a alterações freqüentes. SGML também suporta a inclusão de outros
tipos de dados não textuais.
Pelo fato de aparentemente ser pouco provável que um sistema de publicação
completamente automático, que não requeira intervenção humana, venha a ocorrer, um
outro critério levado em consideração durante o desenvolvimento do padrão foi que o
markup deveria ser legível por “humanos”.
SMGL é como ODA (veja seção 3.5) no sentido em que modela documentos
como árvores, mas ao contrário de ODA, SGML descreve apenas a estrutura lógica dos
documentos, não a sua semântica de layout.
Itens lógicos em SGML são chamados elementos. Cada elemento é delimitado por
marcas que indicam o seu começo e fim. O conteúdo do elemento (que pode conter
elementos aninhados) ocorre, entre as marcas. SGML permite ao usuário definir atributos
a serem adicionados aos elementos.
Apesar do nome, SGML não é uma linguagem, pois o markup em si não é
padronizado, mas uma metalinguagem que proporciona os meios para definir as regras de
markup a serem usadas. SGML define sintaxe mas não define semântica.
3.6.1 Um documento SGML
Um documento SGML é composto de três partes:
1. A declaração SGML;
2. A Definição de Tipo de Documento (Document Type Definition - DTD);
3. A instância do documento.
3.6.1.1 A declaração SGML
A declaração SGML inclui informação sobre o uso de conjuntos de caracteres, a
sintaxe concreta, requisitos de processamento e caraterísticas opcionais.
3.6.1.2 A Definição de Tipo de Documento
A Definição de Tipo de Documento (DTD) é o centro de SGML. Ela define as
regras que se aplicam a todos os documentos daquele tipo incluindo o nome dos vários
Página 48
Padrões para troca de documentos hipermídia
elementos (identificadores genéricos) permitidos, quaisquer atributos eles podem ter, o
número de vezes que podem aparecer, a ordem que eles devem aparecer, se algum markup
(tais como de início e fim) pode ser omitido e o relacionamento entre os elementos.
Um DTD não tem informação sobre como processar um documento ou o como ele
deve parecer, mas permite aos usuários definirem sua própria linguagem de markup
dependendo das suas necessidades.
Figura 9 mostra uma Declaração de Tipo de Documento (que pode incluir
diversas DTDs) onde os itens entre [ e ] representam um DTD. O DTD define o
documento de classe carta que deve consistir do nome do destinatário, o endereço do
destinatário, o nome do remetente, uma saudação, a data e um ou mais parágrafos, nesta
ordem.
Um DTD define três tipos de comandos de markup:
• Elementos: que são marcados com símbolos chamados start-tag e end-tag para a
delimitação do início e fim do markup. Por exemplo, na Figura 10 <rn> </rn> é um
elemento (na forma mais simples possível) cuja start-tag é “<rn>”, end-tag “<rn>” e
com um identificador genérico (generic identifier) “rn” (também denominado nome
da marca ou tag name);
• Atributos: que proporcionam informação extra sobre o elemento que está sendo
especificado. Atributos são similares a parâmetros em linguagens de programação.
• Entidades: que são seqüências de caracteres (strings) usadas para marcar lugares no
texto onde material externo, tais como figuras, ou símbolos matemáticos que não
podem ser entrados diretamente do teclado, devem ser posicionados.
<!DOCTYPE carta[
<!ELEMENT carta - - (nd, ed, nr, sd, d, p+)>
<!-- carta components:
nd
= nome do destinatário
ed
= endereço do destinatário
nr
= nome do remetente
sd
= saudação
d
= data
p
= parágrafo -->
<!ELEMENT (nd|ed|nr|sd|d|p) - (#PCDATA)>
]>
Figura 9 Exemplo de uma Definição de Tipo de Documento (DTD)
3.6.1.3 A instância do documento
A instância do documento representa o documento propriamente dito que é ser
marcado de acordo com as regras estabelecidas da declaração SGML e no DTD. A Figura
10 dá um exemplo de uma instância de documento SGML.
Página 48
Padrões para troca de documentos hipermídia
<!DOCTYPE CARTA SYSTEM “carta.dtd”>
<carta>
<nd>O Editor -- Revista de Verão</rn>
<ed> São Paulo - SP</ra>
<nr>João da Silva </sn>
<sd>Prezado Senhor,</sl>
<d>10/06/96</d>
<p>Por favor cancele a minha
assinatura ….</p>
</carta>
Figura 10 Exemplo de uma instância de um documento do tipo carta (definido na
Figura 9)
3.6.2 Troca de documentos SGML
Documentos SGML são trocados usando o Formato de Troca de Documentos
SGML (SGML Document Interchange Format - SDIF) definido pelo padrão ISO 9069
[ISO, 1988]. SDIF foi originalmente definido para proporcionar os ganchos que
permitissem a troca de documentos SGML dentro de um ambiente OSI.
Um documento SGML pode ser composto de diversas partes separadas tais como
a definição de tipo de documento, definições de entidades externas, etc., e o padrão não
especifica como estas partes estão organizadas. SDIF define com empacotar as partes
dentro de um único fluxo (stream) de dados com descritores indicando como as partes
estão relacionadas entre si. O fluxo de dados é codificado usando ASN 1, o que permite
que SGML seja compatível e usado com padrões de rede [van Herwijnen, 1994] definidos
em termos do Modelo de Referência OSI.
3.6.3 SGML binário (SGML-B)
As marcas de SGML claramente adicionam uma grande sobrecarga aos dados
sendo transmitido. SGML-B é uma extensão ao padrão SGML para proporcionar
codificação binária a SGML com conversibilidade bidirecional entre as formas de texto e
binárias. SGML-B usa um mínimo de markup com o objetivo de reduzir armazenamento.
3.6.4 Limitações de SGML
Uma das grandes limitações de SGML é que ele na verdade não especifica
documentos mas DTDs, e DTDs incompatíveis destroem o objetivo de uma troca
universal de documentos. Uma outra limitação é que os DTDs não indicam como
processar objetos não textuais. Quando objetos não textuais são encontrados, os DTDs
simplesmente especificam seqüências especiais de markup denominadas “escapes”
(seqüências que suprimem o reconhecimento de markup quando uma extensão de código
está em uso) que fazem com que o programa de processamento saia do processo SGML
para uma aplicação que sabe manipular o objeto não textual. SGML também não
padroniza nem mesmo como os objetos são marcados para transferência para estes
processos internos nem como estas aplicações interpretarão os objetos uma vez recebidos.
Página 48
Padrões para troca de documentos hipermídia
Uma solução parcial para estas limitações é oferecida pela linguagem de
estruturação HyTime (Hypermedia/Time based) descrita na próxima seção.
3.7 HyTime
HyTime, ou Hypermedia Time-Based Structuring Language [ISO, 1992] [Markey
1991][Newcomb at al., 1991][Fujitsu and TechnoTeacher, 1995] é o resultado de um
projeto do Instituto Nacional Americano de Padrões (American National Standard
Institute - ANSI) com o objetivo de criar uma Linguagem Padrão de Descrição de Música
(Standard Music Description Language - SMDL). HyTime se tornou um padrão da ISO
em abril de 1992.
HyTime é uma aplicação de SGML (e considerado o seu futuro por Goldfarb) que
permite que markup e DTDs sejam usados para descrever a estrutura de documentos
multimídia. Os tipos de conteúdo que um documento pode conter incluem:
• Gravação digital de audio;
• Imagens dinâmicas e vídeo digital;
• Campos textuais;
• Notação musical;
• Controle de instrumentos;
• Sinais de controle para sistemas externos.
HyTime elimina algumas das limitações de SGML por proporcionar um meio
uniforme de marcar objetos textuais e não-textuais de tal forma que eles possam ser
apresentados como um documento completo ou processados como objetos independentes.
HyTime não especifica como objetos de um documento são codificados ou interpretados
por programas de computados. No entanto, por usar mecanismos padrões de ligação
(linking), alinhamento, e endereçamento, HyTime garante que estes objetos serão
colocados a disposição de programas de uma forma padronizada.
Com o objetivo de não limitar o seu poder de expressão, HyTime em si não é um
DTD SGML, mas fornece construções e diretrizes (“architectural forms”) para a
construção de DTDs para a descrição de documento hipermídia.
HyTime especifica como conceitos comuns a todos documentos hipermídia podem
ser representados usando SGML. Estes conceitos incluem [Adie, 1994]:
• Associação de objetos dentro de documento os com hiperlinks;
• Definição de inter-relacionamento de objetos no tempo e espaço;
• Estruturação lógica do documento;
• Inclusão de dados não-textuais no documento.
Um objeto em HyTime é parte de um documento, e não é dependente do meio:
pode ser um vídeo, uma seqüência de áudio, um texto, um programa, imagens, etc.
Página 48
Padrões para troca de documentos hipermídia
HyTime é composto de seis módulos (Figura 11):
• O módulo base: provê uma forma arquitetural que monta o documento em si
(consequentemente é requerido por todos os outros módulos), incluindo um modelo
léxico descrevendo os conteúdos dos elementos; mecanismos para identificar
políticas para lidar com alterações sobre o documento, ou percorrer um link
(“activity tracking”); e a habilidade de definir “entidades containers” (“container
entities”) que podem manter múltiplos objetos de dados.
• O módulo de medidas: provê os documentos da capacidade de representar conceitos
envolvendo dimensão, medidas e contagem. Ele permite que um objeto seja
localizado no tempo e/ou no espaço, ou em qualquer outro domínio que possa ser
representado por um espaço de coordenadas finitas, dentro de uma “caixa”
(bounding box) denominada “evento”, definida por um conjunto de pontos de
coordenadas que podem ser representados em quaisquer unidades.
• O módulo de localização de endereços: provê mecanismos, em adição aos já
fornecidos por SGML, para identificar e fazer referências a elementos. Este módulo
provê uma forma arquitetural especial (named location address) que pode ser usada
para fazer referência indireta a dados que envolvem mais de um elemento, ou que
esteja localizado em entidades externas. Os dados também podem ser endereçados
indiretamente através de consultas (queries), que devolvem endereços de objetos
dentro de algum domínio que tenha as propriedades que satisfaçam a consulta. Se o
módulo de medidas for usado, as localizações podem ser especificadas como
endereços numéricos ou índices ao longo de dimensões particulares.
HyTime oferece três tipos de endereçamento:
1. Endereçamento por nome-espaço onde um único nome é fornecido;
2. Endereçamento coordenado que é relativo a uma dada localização;
3. Endereçamento semântico que é especificado por descrição.
• O módulo de escalonamento: especifica como eventos em um Espaço de
Coordenadas Finitas (Finite Coordinate Space FCS) devem ser mapeados sobre um
FCS destino. Por exemplo, eventos em um eixo de tempo podem ser projetados
sobre um eixo espacial para ser exibido graficamente, ou um eixo de tempo “virtual”
como os usados em música podem ser projetados sobre um eixo de tempo físico.
Em um outro exemplo, se um mapa deve ser representado em, digamos, uma escala
de 1:100000, isto quer dizer que uma dimensão de 1 km no FCS original será
mapeado para 1 cm no FCS de destino. Se o evento for aplicado para todo o mapa,
isto significa que a mesma ênfase será dada para todas as suas partes. Se, no
entanto, quisermos que algumas partes tenham mais detalhes, mais de uma projetor,
com diferentes escopos de ação (proscopes) podem ser usados. Uma escala de
proscopes é denominada uma “batuta” (baton) e determina a taxa pela qual
unidades virtuais devem ser convertidas em unidades físicas.
Um FCS pode conter qualquer número de escalas de eventos e cada escala pode
conter qualquer número de eventos.
Página 48
Padrões para troca de documentos hipermídia
• O módulo de apresentação (rendition): permite que objetos individuais sejam
modificados antes da apresentação. O módulo especifica como eventos em um
espaço finito de coordenadas pode ser mapeado em outro espaço de coordenadas
finitas. Um exemplo é a modificação de cores em uma imagem de tal forma que ela
possa ser mostrada usando o mapa de cores correntemente selecionado em um
terminal gráfico, ou a alteração do volume em um canal de áudio de acordo com o
gosto do usuário.
Neste caso, objetos são modificados dentro de eventos e nem a semântica dos objetos
nem a dos modificadores são definidos por HyTime. De forma similar à batuta definida
anteriormente, o escopo de um modificador é especificado por um modscope e uma
escala de modscopes é denominada uma “varinha de condão” (wand).
As aplicações não precisam necessariamente suportar todos os módulos: apenas as
partes de HyTime que são apropriadas para um dado documento têm que ser suportadas.
Por ter sido definido como um formato para representação de documentos,
HyTime possui um grande poder de expressão mas não é otimizado para ser eficiente em
tempo de execução.
base
medidas
localização
de endereços
escalonador
hiperlinks
rendition
Figura 11 Módulos de HyTime
3.7.1 A máquina HyTime (HyTime engine)
A máquina HyTime é basicamente um programa que reconhece as construções de
HyTime em um documento. O padrão HyTime não especifica como a máquina deve
“funcionar”. Atualmente há poucas máquinas disponíveis: existe pelo menos um sistema
comercial — HyMinder desenvolvido pela TechnoTeacher [Adie, 1994]; e uma
desenvolvida pelo Interactive Multimedia Group da Universidade de Massachussets
(Lowel) [Koegel at all., 1993].
Página 48
Padrões para troca de documentos hipermídia
3.7.2 Troca de documentos HyTime
Como HyTime é uma aplicação de SGML, a troca de documentos é possível pelo
uso de SDIF (seção 3.6.2).
3.7.3 A Linguagem de Descrição de Música Padrão (Standard Music
Description Language SGML)
A Linguagem de Descrição de Música Padrão [Newcomb, 1991] é uma aplicação
de HyTime com a adição de ferramentas para a representação de música. HyTime foi
originalmente desenvolvido a partir de um projeto com o objetivo de representar música.
A SMDL define quatro domínios de informação (Figura 12):
Domínio
Visual
Score
Análise
Score
Domínio
Analítico
Análise
Domínio lógico
(CANTUS)
Performance
Domínio
Gestural
Performance
Figura 12 Domínio de descrição em SMDL
1. Domínio visual: contém as informações de partitura (score);
2. Domínio gestural: contém as informações da performance;
3. Domínio analítico: contém informação teórica e facilita discussões musicológicas e
teóricas sobre a estrutura da música, transformações temáticas, performance e
técnicas analíticas.
4. Domínio lógico (cantus): pode ser definido como “altura” (freqüência) e durações
(tempos) e contém as informações mínimas para que um autômato gere uma
partitura e uma performance sintética mínima.
Página 48
Padrões para troca de documentos hipermídia
Um cantus pode ser referido por mais de uma performance (domínio gestural) e
por mais de uma partitura. Um documento também pode conter mais de uma edição
“imprimível” da música (domínio visual).
Em SMDL, uma trecho de música é visto como uma combinação de eventos. Os
eventos ocorrem em escalonamentos líricos e de teia (Figura 13) em um espaço de tempo
finito, com uma posição (início) e duração. Começo e duração podem ser definidos por
uma posição explícita ou por referência a outros eventos.
Para representar unidades de tempo, que não necessariamente são as mesma em
música, SMDL usa uma batuta de HyTime. Outras unidades de processamento tais como
modificações e filtros são especificados por uma vara de condão de HyTime na qual toda
semântica dos modificadores é definida pelo usuário.
Cantus:
eventos escalonados em
tempo virtual
BATUTAS
CONTINUAÇÕES
notas
acordes
pausas
LETRAS
direções de tempo
VARAS DE
CONDÃO
modificadores
Figura 13 Estrutura do Cantus em SMDL
Página 48
Padrões para troca de documentos hipermídia
3.7.4 Comentários finais
HyTime proporciona construções muito poderosas para
a definição de
documentos complexos com dependências de tempo e de sincronização. Parte de sua
força é derivada do fato que ele começou como um projeto para a representação de
música. Uma das características mais interessantes de HyTime, e que o faz particularmente
adequado para a representação de hipermídia, é que ele permite a definição de hiperreferências baseadas no conteúdo dos dados em adição a definição de restrições
dependentes de tempo.
Um ponto fraco de HyTime, quando usado para representar hipermídia, vem
diretamente de seu ponto mais forte. Por possuir um grande poder de expressão, e
permitir a definição de documentos em um nível muito alto de abstração, HyTime requer
uma grande capacidade de processamento e conseqüentemente não é muito eficiente em
termos de apresentação das informações.
3.8 Adobe Acrobat
Embora o Acrobat [adobe, 1995] não seja um padrão para troca de documentos,
ele foi inventado e lançado no mercado pelos criadores da Linguagem de Descrição de
Página (PDL) PostScript que é o padrão de facto no mundo das impressoras. O objetivo
da Adobe é o de atingir o mesmo nível de aceitação para documentos eletrônicos. O
Acrobat tenta atingir estes objetivos pelo uso de tecnologias já testadas e aprovadas como
EPS (Encapsulated PostScript) e fontes com Multiple Masters (uma tela do Acrobat é
mostrada na Figura 14).
O Formato Portável de Documentos (Portable Document Format - PDF) do
Acrobat usa uma linguagem de descrição de páginas (PDL) baseada em PostScript para a
descrição de textos, gráficos e imagens em um arquivo com facilidades adicionais para
anotações e referências. Por ser baseado em PostScript, uma arquivo PDF é independente
de dispositivo e de resolução e consequentemente pode reproduzir as páginas na maior
resolução suportada pelo dispositivo de saída.
A Adobe publicou PDF como uma padrão aberto, permitindo que pessoas que
desenvolvem software suportem o formato em aplicações de terceiros.
O Acrobat é composto de um conjunto de pacotes com objetivos específicos:
• Acrobat Exchange: é o pacote para ler e escrever documentos portáveis;
• Acrobat Reader: é capaz apenas de ler documentos criados usando o
Exchange;
• Acrobat Distiller: também usado para criar documentos. Ele proporciona uma
forma mais simples de criação de documentos do que o Exchange por suportar
apenas PostScript encapsulado de nível 2 criado por outros pacotes e fazendo a
conversão para PDF.
Página 48
Padrões para troca de documentos hipermídia
O Acrobat proporciona ainda facilidades para a adição de referências, notas e
marcas (book marks) a documentos embora não permita a identificação de quem criou as
marcas.
3.8.1 Limitações do Acrobat
Apesar de ser muito poderoso para a conversão de documentos no formato
PostScript, Acrobat não é uma ferramenta geral de hipermídia, pois não foi
(originalmente) projetado para tirar vantagens de distribuição, e não é diretamente
extensível para acomodar novos tipos de dados (mídia). Uma outra importante limitação
de Acrobat é o fato de baseado em página.
O ambiente natural para o uso de Acrobat parece ser o de escritórios, onde
proporciona uma boa solução para a redução do volume de papeis, e não como uma
ferramenta hipermídia em geral principalmente pela sua corrente falta de mecanismos de
extensão.
Página 48
Padrões para troca de documentos hipermídia
Figura 14 Exemplo de uma tela do Acrobat
3.9 A World Wide Web
A World Wide Web (WWW ou W3 ou simplesmente “a rede”) é uma arquitetura
cliente servidor mundial para a recuperação de documentos hipermídia na Internet. A
WWW começou como um projeto no CERN como uma sistema distribuído multimídia em
larga escala para proporcionar recursos para a distribuição de documentos relacionados
com a pesquisa de física de altas energias. A rede desde então se espalhou para outras
áreas e é provavelmente o mais conhecido e usado sistema multimídia distribuído
disponível atualmente com “navegadores” (browsers) disponíveis para virtualmente todos
os sistemas operacionais, com configurações desde terminais burros até sofisticadas
estações de trabalho gráficas.
O usuário vê a rede como uma coleção de nós (documentos) e ligações entre eles.
A navegação é normalmente iniciada com um click do mouse sobre uma âncora que
dispara a referência associada e provoca a recuperação do documento associado. A rede
Página 48
Padrões para troca de documentos hipermídia
também possui recursos que permitem pesquisa em fontes de informação remotas, como
por exemplo bibliografias, listas telefônicas e manuais.
A rede oferece interfaces transparentes para Gopher, Wais, ou ftp anônimo,
permitindo acesso a virtualmente todos os recursos disponíveis na Internet. A
identificação de recursos na rede é feita pelo uso de Localizadores Uniformes de Recursos
(Uniform Resource Locators - URL) que são descritos a seguir.
3.10 Localizadores Uniformes de Recursos (Uniform Resource
Locator - URL)
A WWW utiliza um esquema de nomes denominado Localizadores Uniformes de
Recursos (URL) [Berners-Lee, 1995] para representar ligações hipermídia e referência
para recursos compartilhados.
A sintaxe do URLs identificam documentos em termos do protocolo utilizado para
a sua recuperação, seu servidor Internet e a localização dentro do servidor (path name)
http://www.ufg.br/dei/sobre_o_dei.html
protocolo
servidor
(host)
localização ou caminho
(path)
Figura 15 Exemplo de uma URL
conforme mostrado na Figura 15. Entre os protocolos suportados estão http, telnet, ftp
(anônimo), NNTP, wais e gopher. Um problema dos URLs é o fato deles geralmente
dependerem de servidores específicos. No entanto, trabalhos estão em andamento com o
objetivo de proporcionar identificadores “eternos” que são independentes de localização.
A existência destes identificadores permitirá a utilização de serviços de diretórios
automatizados similares ao X.500 [CCITT, 1988] para a localização da cópia mais
próxima de um determinado recurso [Raggett, 1994a].
3.11 Números Universais de Recursos (Universal Resource Numbers
- URN)
Os Números Universais de Recursos (URN) são um sistema proposto para
permitir identificadores únicos independentes de tempo para arquivos disponíveis por rede
em desenvolvimento por grupos de trabalho da IETF. Os URNs, ao contrários dos URLs,
não contém informação sobre como os nós devem ser recuperados e podem ser alocados a
nós e representados em âncoras de origem.
O objetivo dos URNs é reduzir o tráfego na rede e oferecer uma estrutura mais
robusta onde a localização do servidor não é codificada. O sistema do leitor não precisa
buscar um nó se ele já estiver disponível localmente. A implementação de mecanismos de
cache é facilitada por que a identificação não se altera, e qualquer servidor com o objeto
referido pela URN pode oferecê-lo. Por outro lado, se o nó for alterado, todas as
Página 48
Padrões para troca de documentos hipermídia
referências para aquele nó devem ser atualizadas invalidando as caches existentes. Este
esquema, consequentemente, só é útil para nós “grandes”, que impõem um alto custo de
transmissão para sua recuperação e que pouco provavelmente serão atualizados.
3.12 A Linguagem de Markup de Hipertexto (Hypertext Markup
Language HTML )
A Linguagem de Markup de Hipertexto (HTML) [Berners-Lee, 1993] é a
linguagem usada pelos navegadores da rede. HTML descreve a organização de
documentos de tal forma que elementos estruturais podem ser identificados e recuperados
na Internet.
<TITULO> Aqui vem o título do documento</TITULO.
<H1> O cabeçalho principal está aqui</H1>
<H2>E aqui um cabeçalho de nível 2<H2>
<P>Temos agora o primeiro parágrafo</P>
<H2>Mais uma subseção de nível 2</H2>
<P>E o segundo parágrafo.</P>
<P>Esta é uma referência para a WWW
< A
HREF=”http://www.w3.org/hypertext/WWW/TheProject”>(World Wide
Web) </A>
Figura 16 Exemplo de um documento HTML
Um documento HTML é um arquivo ASCII com marcas adicionadas (markup),
com uma sintaxe baseada em SGML, que provêm uma estrutura hierárquica ao texto
[Barry, 1994]. HTML inclui elementos de markup para:
• Cabeçalhos: seis níveis de cabeçalhos são suportados e eles são marcados de H1 (o
de maior significância) a H6 (o menos significante). Usualmente o nível de
significância definirá o tipo e o tamanho do fonte utilizado para mostrar o cabeçalho;
• Parágrafos: textos normais são normalmente ajustados ao tamanho da janela pelo
navegador, e um parágrafo tem usualmente apenas uma marca de início de fim. A
marca de terminação pode ser implícita;
• Vários tipos de ênfase em caracteres;
• Referências de hipertexto: uma referência de HTML é definida por uma URL. No
exemplo acima, a referência (< A HREF= ”http: //www.w3.org/hypertext/WWW/TheProject”> (World Wide Web) </A>)
conectará o usuário a home page na www.w3.org usando o protocolo http. A única
parte da referência que os navegadores fazem visível ao leitor é (World Wide Web)
que pode ser selecionada (com uma mouse) para ativar a referência.
• Listas;
Página 48
Padrões para troca de documentos hipermídia
• Texto pré-formatado;
• Facilidades para buscas simples.
3.12.1 HTML+
HTML+ [Ragget, 1993a, Ragget, 1993b, Ragget, 1994a] é um super conjunto de
HTML que acrescenta características extras tais como figuras, tabelas e formulários. Ele
também generaliza estruturas presentes em HTML para facilitar o processo de conversão
entre HTML+ e outros formatos. HTML+ formaliza o conceito de listas aninhadas
proporcionando vários tipos de estilos de listas. Listas desordenadas também são
implementadas o que permite a definição de elementos de menus.
3.13 O Ambiente de Apresentação para Objetos Multimídia
(Presentation Environment for Multimedia Objects PREMO)
O Ambiente de Apresentação para Objetos Multimídia (PREMO) está sendo
desenvolvido pelo ISO/IEC JTC1/SC24 [ISO, 1994b] [ISO, 1994a] [Stenzel at al., 1994]
que é o grupo responsável por processamento de imagens e computer graphics. O
objetivo principal do projeto é adicionar apresentação e interação com mais de um meio.
PREMO deve, consequentemente, fazer uso de padrões para um único meio em
desenvolvimento pela ISO. Como PREMO lida principalmente com os aspectos de
representação de multimídia, ele é distinto e deve ser usado em conjunto com outros
padrões da ISO/IEC tais como ODA, HyTime e MHEG [Herman et al., 1994, Stenzel et
al.,1994].
PREMO está sendo projetado para atender as necessidades das novas aplicações
multimídia e novas funcionalidades adicionadas às modernas estações de trabalho. Ele é
uma arquitetura aberta que proporciona facilidades para configuração, extensões e
customização dependendo dos requisitos das aplicações, e deve ser capaz de atender a
uma larga gama de usos desde CAD/CAM até realidade virtual.
PREMO é orientado a objetos e baseado no modelo proposto pelo Object
Management Group (OMG) [Digital Equipment et al., 1993]. Isto deve fazê-lo portável e
usável em um ambiente heterogêneo distribuído.
O trabalho do grupo que desenvolve PREMO ainda não está muito avançado e
nãoé esperado que ele se torne padrão internacional antes de 1997.
3.14 Considerações finais
Esta seção apresentou uma introdução a um conjunto de padrões existentes e
emergentes para a estruturação de aplicações hipermídia. Desses, os mais importantes são
SGML, HyTime, ODA, PREMO e Acrobat. Exceto pelo último, todos são padrões “de
jure”; Acrobat é um produto comercial que está sendo proposto como um padrão “de
facto”.
Página 48
Padrões para troca de documentos hipermídia
O interesse em SGML e HyTime tem crescido recentemente, especialmente entre
editoras (onde SGML foi originado), enquanto que parece haver uma queda de interesse
por ODA.
PREMO ainda não é bem conhecido e não parece claro que um novo padrão com
grandes partes que se sobrepõem a MHEG, HyTime e outros padrões gráficos seja
necessário a curto prazo.
Embora Acrobat seja um produto relativamente recente, o fato dele ser baseado
em tecnologias bem conhecidas o faz um forte candidato a se tornar um padrão como é a
intenção da Adobe.
Um outro importante padrão emergente “de jure” é MHEG que será apresentado
na próxima seção.
4. MHEG
O Multimedia and Hypermedia information coding Expert Group (MHEG) é o
grupo de trabalho da ISO WG12. O padrão em desenvolvimento pelo grupo é a
representação codificada de base de objetos de informação multimídia e hipermídia em
forma final”.
O trabalho sendo desenvolvido pelo MHEG sobre o título geral de Tecnologia da
Informação - Codificação de Informação Multimídia e Hipermídia1 tem como objetivo a
produção dos seguintes documentos:
• 13522-1 MHEG Object Representation, Base notation (ASN.1): este é o documento
em estágio de desenvolvimento mais avançado tendo atingido o status de Padrão
Internacional recentemente e atualmente está em fase de publicação. No texto,
exceto onde explicitamente dito, estaremos fazendo referência a este documento;
• 13522-2 Notação alternativa (SGML): este documento proverá uma notação
alternativa a ASN.1 e deve ter maior desenvolvimento após o término da fase
anterior.
• 13522-3 Extensões a MHEG para apoio a linguagens de “scripting”: ainda em
fase inicial de desenvolvimento uma vez que inicialmente MHEG não previa a
inclusão de linguagens de scripting. Não há ainda data prevista para que MHEG 3 se
torne padrão sendo que em junho de 96 foi votado o “rascunho de padrão
internacional” (Draft of International Standard)
• 13522-4 Procedimentos de Registro para Identificadores de Formato: também em
estágio adiantado de desenvolvimento. MHEG 4 foi aprovado recentemente como
Padrão Internacional e encontra-se em fase de publicação;
1
Information Technology - Coding of Multimedia and Hypermedia Information
Página 48
Padrões para troca de documentos hipermídia
• 13522-5 Sub-conjunto de MHEG para implementação em nível básico: este é um
item novo adicionado ao trabalho do MHEG em novembro de 1994. MHEG 5
define um subconjunto de MHEG para ser aplicado a aplicações cliente/servidor
“simples” tais como vídeo sob demanda e sistemas folheadores (browsing systems).
MHEG 5 deve se tornar Padrão Internacional em 1997 ou 1998. Em maio de 96 foi
votado o “rascunho de padrão internacional” (Draft of International Standard).
• 13522-6 Apoio para aplicações interativas avançadas (Support for Enhanced
Interactive Applications): é o documento mais recente da série tendo o seu
desenvolvimento começado em novembro de 1995.
As seções seguintes apresentarão em detalhe os trabalhos desenvolvidos pelo
MHEG, em particular as partes 1 (que já se tornou Padrão Internacional) e 5 (que cobre
um bom número de aplicações). Além de apresentar as características do Padrão, o texto
procura mostrar as dificuldades e a evolução do processo de se definir um padrão
Internacional para a troca de objeto hipermídia.
Uma introdução mais detalhada a MHEG pode ser encontrada em [Casey1994],
[Colaitis e Bertrand1994], [Markey 1991] e [Meyer-Boudnik e Effelsberg1995].
4.1 Objetivos do projeto
O padrão MHEG tem como foco os aspectos genéricos de estruturação dos
objetos multimídia e leva em consideração os seguintes requisitos:
• Uso em sistemas com recursos mínimos;
• Interatividade e sincronização multimídia;
• Apresentação em tempo real;
• Troca de objetos em tempo real;
• Representação em forma final o que significa que os objetos MHEG não precisam
de nenhum processamento extra para serem apresentados uma vez que a troca foi
efetuada. Por exemplo, uma referência MHEG (link) uma vez transmitido será
executada sem que seja preciso fazer nenhuma computação extra uma vez que tanto
a origem como os destinos da referência devem estar completamente resolvidos.
4.1.1 Adequação de MHEG
Por definir objetos em forma final, MHEG não é adequado para sistemas de
autoria altamente interativos. No entanto, ele é particularmente adequado para sistemas de
leitura e navegação como por exemplo, a apresentação de uma coleção de objetos
multimídia armazenados em um CD-ROM.
Página 48
Padrões para troca de documentos hipermídia
4.2 Escopo de MHEG
A Figura 17 mostra o escopo de MHEG, ilustrando os diferentes níveis onde a
troca de informação multimídia ocorre:
Troca
Aplicação
Script
APL
Aplicação
S
Script
M
Obj. MHEG
Escopo de MHEG
Obj. MHEG
OBJ. não
MHEG
elementos
outro PROT.
C
OBJ. não
MHEG
EOP
elementos
outro PROT.
Figura 17 Escopo de MHEG
1. Nível da aplicação: as infinitas variedades que podem existir no nível de aplicação a
faz inadequada para padronização. Uma aplicação pode, no entanto, usar o nível de
script para trocar objetos.
2. Nível de script: MHEG 1 não faz nenhum esforço para padronizar linguagens de
scripting. Linguagens de scripting devem usar o nível inferior (MHEG) para trocar
objetos. Os trabalhos do grupo que desenvolve MHEG-3 (Extensões a MHEG para
apoio a linguagens de “scripting”) ainda não atingiram um estágio que permita
uma completa avaliação deste nível. A grande dificuldade imposta por relações
complexas definidas por linguagens de scripting está na sua potencial ineficiência
uma fez que objetos podem ter que ser computados em tempo de execução para sua
apresentação.
3. Nível dos objetos MHEG: aqui está o escopo de MHEG que será discutido em
detalhes nas próximas seções.
4. Nível de objetos não MHEG: este é o nível onde padrões para troca “monomídia”
são usados. MHEG faz uso de outros padrões neste nível (por exemplo, JPEG e
MPEG).
Página 48
Padrões para troca de documentos hipermídia
5. Nível de elementos de outros protocolos: este é o nível mais baixo de troca.
Protocolos para mensagens e reconhecimentos (acknowledgments) estão incluídos
neste nível
6. Representação de objetos: Objetos são codificados usando ASN.1 ou SGML
(representação alternativa).
4.3 Estrutura de MHEG
MHEG é baseado em três conceitos:
1. Classes MHEG, Objetos MHEG: as classes MHEG representam os objetos que
são trocado de fato. O sistema de run-time pode criar qualquer número de
objetos de uma classe de objetos dada;
2. Objetos de run-time (rt-objects): Os objetos de run-time não são trocados entre
aplicações, mas a sua existência é disparada dinamicamente pelo sistema de runtime. Objetos criados de subclasses de Model (Figura 18) podem ser reusados
em contextos diferentes. Cada vez que um objeto deste tipo é criado, uma
instância de um objeto run-time é definida. Por exemplo, uma imagem pode ser
trocada uma vez mas usada diversas vezes com diferentes atributos tais como
tamanho e cor. Elementos em um composto run-time são chamados sockets.
3. Canais (channels): canais definem espaços lógicos no qual objetos run-time são
apresentados.
O padrão define uma representação baseada em objetos de entidades multimídia,
com uma árvore de herança simples conforme mostrado na Figura 18. A hierarquia define
a herança de dados mas não define métodos de classe consequentemente não se pode dizer
que a representação é orientada a objetos. MHEG também não força nem define um
modelo orientado a objetos para um sistema MHEG; não é feita nenhuma suposição a
MH-OBJECT>
ACTION
LINK
MODEL>
SCRIPT
COMPONENT>
CONTENT
MULTIPLEXED CONTENT
COMPOSITE
CONTAINER
DESCRIPTOR
Figura 18 Hierarquia de Classes de MHEG
Página 48
Padrões para troca de documentos hipermídia
respeito da representação interna de sistemas.
4.4 Evolução de MHEG
Análise da evolução da hierarquia de classes sofrida por MHEG desde o início de
seus trabalhos até a versão corrente dá uma idéia das dificuldades encontradas pelo grupo
na definição do padrão.
A Figura 19 mostra a hierarquia proposta em uma das primeiras versões do padrão
em 1991. A Figura 20 mostra as hierarquias em 1992 e a atual. A hierarquia proposta em
91 mostra uma quantidade exagerada de detalhes, quase ao nível de um conjunto de
widgets gráficos, definindo formas de entrada e saída. A estrutura era também muito
limitadora no sentido que os tipos de dados eram definidos na hierarquia (texto, gráficos
(graphics), imagens, audio e audiovisual), conseqüentemente a estrutura básica teria que
ser alterada para a adição de uma mídia nova.
A hierarquia de 1992 (Figura 20 esquerda) era mais limpa mas os tipos de mídias
suportados ainda eram pré definidos proporcionando pouco suporte para extensões.
Página 48
Padrões para troca de documentos hipermídia
MH-OBJECT
ALL-OBJECT>
CONTENT>
OUPUT-CONTENT>
TEXT CONTENT
GRAPHICS CONTENT
STILL PICTURE CONTENT
AUDIO CONTENT
AUDIO VISUAL SEQUENCE CONTENT
INPUT-CONTENT>
ACTION-BUTTON CONTENT
STAY-ON BUTTON CONTENT
ON-OFF BUTTON CONTENT
MENU-SELECTION
MULTIPLE SELECTION
CHARACTER STRING BY TYPING CONTENT
CHARACTER STRING ON SELECTION CONTENT
MULTIPLE CHARACTER STRING CONTENT>
FORM FILLING CONTENT
MULTIPLE CHARACTER STRING ON SELECTION CONTENT
LOCATION CONTENT
NUMERICAL VALUE CONTENT
PROJECTOR
OUTPUT PROJECTOR>
AREA PROJECTOR>
TEXT PROJECTOR
GRAPHICS PROJECTOR
STILL PICTURE PROJECTOR
AUDIO PROJECTOR
AUDIO VISUAL SEQUENCE PROJECTOR
INPUT PROJECTOR>
ACTION-BUTTON PROJECTOR
STAY-ON PROJECTOR
ON-OFF PROJECTOR
MENU SELECTION PROJECTOR
MULTIPLE SELECTION PROJECTOR
CHARACTER STRING PROJECTOR>
CHARACTER STRING BY TYPING PROJECTOR
CHARACTER STRING ON SELECTION PROJECTOR
MULTIPLE CHARACTER STRING PROJECTOR>
FORM FILLING PROJECTOR
MULTIPLE CHARACTER STRING ON SELECTION PROJECTOR
LOCATION PROJECTOR
NUMERICAL VALUE PROJECTOR
COMPOSITE>
COMPOSITE OUTPUT
COMPOSITE INPUT
INTERACTIVE
NULL
Figura 19 Hierarquia de classes MHEG em 1991
Página 48
Padrões para troca de documentos hipermídia
A hierarquia atual (Figura 20 direita) é muito mais genérica, proporcionando um
arcabouço básico para extensões: os tipos de mídia não estão definidos na hierarquia mas
incluidos em subclasses de Model desta forma, qualquer mídia nova será apenas uma nova
instância de uma classe de conteúdo (Content). O modelo é suficientemente abstrato para
MH-OBJECT>
HEADER
CONTENT>
MEDIA CONTENT>
TEXT CONTENT
GRAPHICS CONTENT
STILL CONTENT
AUDIO CONTENT
AUDIO VISUAL CONTENT
NUMERIC CONTENT
PROJECTOR
SPATIAL PROJECTOR
TEXT PROJECTOR
GRAPHICS PROJECTOR
STILL PROJECTOR
AUDIO PROJECTOR
AUDIO VISUAL PROJECTOR
NUMERIC PROJECTOR
PROJECTABLE
INTERACTION
LINK
COMPOSITE
NULL
CLOCK
MH-OBJECT>
ACTION
LINK
MODEL
SCRIPT
COMPONENT>
CONTENT
MULTIPLEXED
CONTENT
COMPOSITE
CONTAINER
DESCRIPTOR
Figura 20 Hierarquia de classes MHEG em 92 (e) e atual (d)
lidar com a adição de novas mídias no nível de troca.
Um ponto importante a ser visto da evolução é que os conceitos gradualmente se
tornam mais claros: as primeiras hierarquias faziam uma mistura entre troca e
apresentação resultando em um formato menos poderoso, com foco (indesejável) na
implementação.
Uma outra evolução importante foi a definição de objetos de run-time (rt-objects).
As primeiras versões de MHEG não faziam referência explícita a objetos de run-time,
embora sua existência tivesse que ser inferida para a implementação de qualquer sistema
de run-time.
A ausência de objetos de run-time explícitos levava também a uma confusão na
identificação dos objetos (naming) quando havia uma tentativa de reusar conteúdos. Por
exemplo, se uma foto era usada mais de uma vez durante uma apresentação, não havia
como fazer a distinção das instâncias específicas uma vez que a identificação (o nome)
usado era de um objeto modelo na hierarquia atual. Não era claro, consequentemente,
como uma aplicação faria distinção entre as diversas instâncias; isto poderia requerer, no
pior caso, uma indesejável troca por mais de uma vez do objeto modelo (o conteúdo) de
tal forma que a aplicação poderia fazer a distinção em termos do modelo. A simples
inclusão no modelo dos objetos de run-time foi suficiente para resolver o problema de
inconsistência de nomes.
Página 48
Padrões para troca de documentos hipermídia
4.5 Nível de abstração em MHEG
A medida que a hierarquia de classes se tornava mais abstrata durante o processo
de evolução de MHEG, a modelagem de aplicações “simples” se tornava mais difícil. Esta
é uma evolução natural quando um padrão está sendo definido. Como um compromisso
entre generalidade e poder de expressão, um padrão para trocas tem que ser capaz de
representar diferentes formatos e, consequentemente, ser tão genérico quanto possível
mas tendo o cuidado de fazer com que o resultado seja de difícil uso (ou mesmo não
usável).
A decisão sobre o que deve ser incluído em um padrão internacional é geralmente
difícil. Se o padrão for muito genérico, é praticamente impossível definir um nível mínimo
compatibilidade. Se, por outro lado, ele tentar incluir as necessidades de apenas um
pequeno grupo de aplicações, pode ser difícil a acomodação de extensões futuras.
Estas dificuldades levaram a discussões, mesmo entre os membros do MHEG,
sobre como definir uma aplicação simples como um hipertexto. Sendo um padrão com o
objetivo de ser genérico, MHEG não trata de problemas apresentados por aplicações
específicas (como hipertexto) e consequentemente pode ser muito pesado para alguns
casos.
No caso específico de hipertexto, trechos de texto podem ser usados como
âncoras para referências. Para ter um suporte adequado para este tipo de abstração,
MHEG deveria suportar diretamente pelo menos o conceito de âncora ou mecanismo
similar. No entanto, se pensarmos em hipermídia em geral, ao invés de simplesmente
hipertexto, o suporte proporcionado é suficientemente genérico já que qualquer objeto de
run-time pode ser “selecionável” e usado como uma âncora. No caso de um documento
com texto apenas no qual seja desejável que toda palavra seja uma âncora, é necessário
definir cada palavra como um objeto individual, o que pode provar que o enfoque
genérico não possui uma boa performance neste nível de granularidade.
A decisão sobre qual deveria ser o escopo de MHEG e consequentemente a
definição de seu nível de abstração foi uma das tarefas mais difíceis do grupo e as dúvidas
se refletiram nas mudanças sofridas na hierarquia de classes. Apesar destas dificuldades, há
pelo menos um projeto —GLASS Globally Accessible ServiceS [Fokus, 1995] [Focus,
1996]— que prova que a estrutura proposta por MHEG 1 é suficientemente poderosa
para modelar hipertexto/hipermídia de modo geral.
Uma evolução natural de MHEG é a mesma sofrida pelo modelo Dexter (discutido
na seção 3.1): o padrão inicialmente proposto é suficientemente genérico para acomodar
todos os usos mas não é suficientemente eficiente para usos específicos. Para lidar com
algumas aplicações especializadas (e comuns) é esperado que sub conjuntos de MHEG
sejam definidos. O próprio MHEG percebeu esta necessidade e propôs a definição de
MHEG 5 que será discutido na seção 4.7.
Página 48
Padrões para troca de documentos hipermídia
4.6 As classes de MHEG
Esta seção apresentará uma visão superficial das classes definidas em MHEG 1.
Para uma melhor análise dos detalhes de cada classe é recomendável que o leitor se
reporte ao texto da ISO.
4.6.1 A classe Mh-Object
“A classe mh-Object provê a identificação dos objetos MHEG”
A classe mh-object é uma classe abstrata, ou seja, não há instâncias de objetos
dessa classe mas apenas de suas subclasses. Mh-objeto fornece (por herança) a
identificação de todos os objetos na hierarquia de MHEG. A identificação inclui a
identificação do padrão e sua versão, a identificação da classe do objeto, o identificador
MHEG e informações genéricas do objeto (nome, dono, versão, data, palavras-chave,
copyright, licença e comentários).
4.6.2 A classe Action
“A classe action define objetos que são usados dentro de um link
para descrever o efeito deste link”
Um objeto da classe Action provê as seguintes informações:
• Indicador de sincronização: indica o tipo de processamento de ações sincronizadas.
Os valores podem ser paralelo ou serial.
• Conjunto alvo: um atributo opcional que especifica os alvos das ações.
• Número de performances: especifica o número de performances das ações
sincronizadas. O valor default é um.
• Ações sincronizadas: o conjunto de ações elementares e/ou objetos de ação.
As ações podem ser aninhadas e nesse caso o alvo default das ações aninhadas é o
definido para o bloco mais externo. O atributo de sincronização é aplicado a todas as
ações. O padrão também prevê a existência de ações macro para otimizar a codificação
de ações complexas ou freqüentemente usadas. Macros também permitem o
compartilhamento de reuso de comportamentos complexos.
Página 48
Padrões para troca de documentos hipermídia
4.6.3 A classe Link
“A classe Link define uma estrutura que define um conjunto de
relacionamentos”
Em MHEG os links são usados em duas situações:
1. Em objetos complexos onde podem definir o posicionamento dos objeto no
tempo e espaço;
2. De forma independente para permitir a criação e modificação de relações
genéricas inter-objetos.
Os links em MHEG têm as seguintes características:
• Direcional: conectam um objeto a um ou mais objetos;
• Condicional: as ações definidas são processadas apenas se as condições são
satisfeitas. As condições podem ser baseadas em atributos dinâmicos do objeto
origem ou em objetos externos.
Todas as condições são devem ser aplicadas ao mesmo tempo e a especificação da
aplicação deve levar em consideração os efeitos de testes seqüenciais. A estrutura de um
link pode ser vista na Figura 21. Pela figura nota-se que o link é formado basicamente por
duas partes: uma condição do link que especifica as condições lógicas que dever ser
satisfeitas para o disparo do link; e o efeito do link que contém as ações a serem
executadas após o disparo do link. A condição do link pode envolver combinações
complexas de disparo mas todas as condições devem estar resolvidas, ou seja, a origem da
condição é conhecida a partir do momento que o objeto é decodificado.
Página 48
Padrões para troca de documentos hipermídia
LINK
condição do link
condição de disparo
Operador
lógico
Operador
lógico
cond
link
cond
cond
disparo link
restrição
resrestri- trição ção
efeito do link
resolução de macros
objeto de ação
Figura 21 Estrutura de um objeto Link
4.6.4 A classe Model
A classe model, assim com Mh-Object, é uma classe abstrata. As subclasses de
modelo são as classes que definem os objetos que são trocados e que podem ser
instanciados (possivelmente mais de uma vez) usando a classe como molde. Por exemplo,
um objeto da classe Content que contém uma imagem é trocado uma vez mas pode ser
instanciado mais de uma vez (criando-se diferentes rt-objets) em diversos contextos. A
criação de um rt-object não afeta o objeto modelo.
4.6.5 A classe Script
“A classe script define um invólucro para relacionamentos
complexos entre objetos MHEG e objetos de run-time, definidos por
uma linguagem não MHEG”
As linguagens de scripting originalmente não faziam parte do projeto de MHEG.
Linguagens externas para especificar comportamentos complexos deveriam ser usados e
Página 48
Padrões para troca de documentos hipermídia
atualmente MHEG 3 está em desenvolvimento para prover scripting dentro do escopo de
MHEG. No entanto, desde as versões iniciais, MHEG prove facilidades para a troca de
objetos de script. Um objeto de script contém:
• A classificação do script: um parâmetro opcional que pode ser usado para
identificar o tipo do dado de script;
• Um gancho de script: quer permite a identificação da linguagem externa de scripting
usada. O gancho de script é composto de uma identificação da linguagem de
scripting e uma descrição da linguagem;
• Os dados do script: a inclusão ou referência ao script propriamente dito.
4.6.6 A classe Descriptor
“A classe Descriptor define a estrutura para a troca de informações
de recursos sobre um conjunto de outros objetos intercambiados”
A classe Descriptor permite a descrição dos objetos trocados de modo que
sistemas de apresentação sejam capazes de adaptar os recursos disponíveis aos requisitos
para um determinado objeto, e também permitir à máquina MHEG determinar se ela é
capaz ou não de prosseguir com uma apresentação. No entanto, não é exigido que todo
objeto trocado tenha um objeto descritor correspondente.
4.6.7 A classe Component
“A classe Component modela objetos que podem ser trocados dentro
ou através de aplicações usuárias”
A classe Component é uma classe abstrata herdada pelas classes Content e
Composite. Como uma classe abstrata ela não contém informação e está presente na
hierarquia para facilitar a organização de suas subclasses.
4.6.8 A classe Content
“A classe Content contem ou faz referência à representação
codificada de informação de uma determinada mídia em conjunto
com um conjunto de parâmetros com as informações necessária para
a apresentação deste conteúdo”
A classe Content é uma subclasse de Model e consequentemente suas instâncias
são trocadas por todas as aplicações e usadas como “molde” para a criação de objetos do
tipo rt-componente. Um objeto do tipo conteúdo contém as seguintes informações:
• Classificação dos dados: parâmetro opcional que provê ajuda para a determinação
do tipo do mídia do dado “percebido”.
Página 48
Padrões para troca de documentos hipermídia
• Percepção original do conteúdo: parâmetro opcional que provê as
“percepções”espaciais e temporais originais (por exemplo, tamanho original,
duração, etc.), e a “percepção” original audível (volume e limites do volume).
• Gancho do conteúdo: o mecanismo de codificação/decodificação usado para
representar os dados.
• Dados de conteúdo: inclusão ou referência para os dados reais.
4.6.9 A classe Multiplexed Content
“A classe Multiplexed Content contém, ou faz referência referência à
representação codificada de informação de mídia multiplexada em
conjunto com a descrição de cada stream multiplexado”
Um objeto da classe Multiplexed Content contem toda informação de um objeto
do tipo content e adicionalmente contém uma lista ordenada que descreve os streams dos
dados multiplexados.
4.6.10 A classe Composite
“A classe Composite provê suporte para a associação de objetos
multimídia e hipermídia”
Um objeto composto contém as seguintes informações:
• Comportamento do composto: uma descrição do sequenciamento e
interrelações entre elementos do composto, incluindo o comportamento inicial.
• O número de elementos na composição;
• A lista de elementos da composição: uma lista de todos os componentes irmãos
na composição.
Um elemento de um composto de run-time (rt-composite) é chamado de socket e
pode ser: vazio, quando um rt-componente nulo está ligado a ele; apresentável
(presentable) quando um rt-componente ou rt-conteudo-multiplexado está ligado a ele; ou
ainda estrutural quando a ligação é com um rt-composto.
4.6.11 A classe Container
“A classe Container proporciona suporte para o reagrupamento de
dados multimídia e hipermídia como o objetivo de intercambiá-los
como um único conjunto”
O objetivo do reagrupamento de objetos é facilitar a troca pois um conjunto de
objetos pode ser transferido dentro de um único objeto garantindo assim que todos os
Página 48
Padrões para troca de documentos hipermídia
componentes estarão incluidos. Um objeto da classe Container não é um “objeto modelo”
consequentemente, não é possível a criação de instâncias de run-time. O objetivo de um
objeto do tipo Container é ser usado exclusivamente como uma “embalagem” para o
transporte de vários objetos como um único “pacote”.
4.6.12 Comentários finais
MHEG representa a primeira tentativa de desenvolvimento de um padrão
internacional para cuidar dos requisitos genéricos para a troca de documentos mutimídia.
Como um padrão que não é voltado para uma aplicação particular, MHEG é muito
genérico e espera-se que diversos subconjuntos voltados para aplicações específias
apareçam (como é o caso de MHEG 5).
MHEG define objetos em forma final, o que o faz eficiente para lidar com
documentos que não requerem mudanças mas inadequado para aplicações de autoria
interativas. Como seus objetos não requerem processamento para serem apresentados, é
possível a implementação de sistemas muito eficientes.
O padrão não define o look-and-feel de uma apresentação. Novamente isto leva a
uma troca eficiente de informação pelo fato do volume de dados a ser transmitido é
reduzido; a forma como os dados serão apresentados podem ser definidos no ponto de
destino. Por outro lado, este enfoque leva a dificuldades se o documento for, por exemplo,
um trabalho artístico onde a forma de apresentação é tão ou mais importante que os dados
em si. Para estes tipos de uso, é possível que MHEG venha a ser utilizado em conjunto
com outros padrões como PREMO.
4.7 MHEG-5
O documento 13522-5 Sub-conjunto de MHEG para implementação em nível
básico (ou simplesmente MHEG 5), foi adicionado ao trabalho do MHEG em novembro
de 1994 com o objetivo de especificar “requisitos para um conjunto básico de objetos
MHEG” [MHEG,1995b] [MHEG,1995c] a serem aplicados ao domínio das “aplicações
multimídia simples”, tais como vídeo sob demanda, aplicações de navegação e
folheadores.
MHEG 5 define um subconjunto de MHEG 1 através da especialização de algumas
de suas classes. As classes definidas definidas por MHEG 5 estão em um nível mais baixo
de abstração em relação a MHEG 1 (de forma similar às primeiras versões deste) e
consequentemente limitam as aplicações que podem ser definidas. No entanto, a autoria de
documentos ou objetos dentro de seu escopo fica bastante simplificada.
As seções seguintes apresentam a estrutura de MHEG 5 e seu relacionamento com
MHEG 1.
4.7.1 Estrutura de MHEG 5
Uma aplicação MHEG consiste em um conjunto de “cenas” das quais apenas uma
é a cena raiz (root) e de um conjunto de referências (links) usados para a implementação
Página 48
Padrões para troca de documentos hipermídia
de comportamentos compartilhados entre as cenas [MHEG,1995b] (Figura 22). As figuras
23 a 25 mostram detalhes da Figura 22.
composição
Raiz
Herança
relação 0-n
Grupo
Aplicação
Ingrediente
Cena
Figura 22 Diagrama do topo da hierarquia de classes de MHEG 5
Uma cena é um agrupamento lógico de objetos que devem ser usado em conjunto.
Uma cena é formada de ingredientes, que podem conter (dentre outros) os seguintes
elementos (Figura 23):
• Presentables (objetos “apresentáveis”) que são os objetos “perceptíveis” tais como
texto, audio, bitmaps, retângulos, hipertextos, etc.
• Listas usadas para agrupar logicamente conjuntos de presentables;
• Fontes usadas por objetos textuais;
• Links que especificam o comportamento (efeito) que ocorrerá quando determinado
evento ocorre;
• Variáveis que podem ser usadas para armazenar o estado de outro ingrediente da
cena. As variáveis podem ser usadas para trocar dados com entidades externas como
um servidor por exemplo.
Página 48
Padrões para troca de documentos hipermídia
Ingrediente
Link
Procedimento
Variável
Apresentável
(Presentable)
Fonte
Palete
Forma de
Cursor
Ação
Figura 23 Hierarquia das subclasses de Ingrediente
Administrador de tokens
Token Manager
Grupo de Molduras
Template Group
Grupo de Tokens
TokenGroup
Presentable
Visível
visible
Audio
Stream
Vídeo
Lista
Ação
RTGraphics
Figura 24 Estrutura das subclasses de Presentable
Página 48
Padrões para troca de documentos hipermídia
Visível
Passível de
interação
Texto
Bitmap
Vídeo
RTGraphics
Linha de arte
Retângulo
Hipertexto
Campo de entrada
Barra deslizante
Button
Hotspot
Botão de pressão
Botão de escolha
Figura 25 Diagrama das subclasses da classe Visível (Visible)
4.7.2 Relacionamento de MHEG 5 com MHEG 1
O relacionamento entre as classes definidas por MHEG 5 e as definidas por
MHEG 1 podem ser vistas graficamente na Figura 26. MHEG 5 limita os tipos de
conteúdos e de compostos que componentes podem especificar ao mesmo tempo que cria
tipos de objetos de uso freqüente em apresentações multimídia tais como botões de
escolha e de pressão, retângulos, textos e vídeos simplificando o trabalho do autor. Um
sistema de run-time para MHEG 5 também tem sua implementação simplificada e os
processos otimizados devido ao poucos tipos de objetos que é obrigado a reconhecer e
manipular.
Página 48
Padrões para troca de documentos hipermídia
Mh-Object
Model
Script
Container
Descriptor
Component
MHEG 1
composite
content
Raiz
MHEG 5
Grupo
Aplicação
Ingrediente
Cena
...
Action
Link
Figura 26 Relacionamento entre MHEG 5 e MHEG 1
4.8 MHEG vs HyTime vs PREMO
Como foi dito anteriormente, devido ao fato de MHEG lidar como objetos em
forma final, seu uso não é adequado para uso em ferramentas de autoria onde as
alterações são frequentes. MHEG também não oferece um nível alto de abstração para
autores uma vez que eficiência foi escolhida sobre poder de expressão por seus autores.
Conseqüentemente, uma possível interação entre os três padrões em desenvolvimento pela
ISO pode ser vista na figura (adaptada de [ISO, 1994a]).
Os pontos fortes e fracos dos três padrões podem ser analisados da seguinte
forma:
• PREMO é muito voltado para implementação, e é capaz de permitir aos usuários a
definição do look-and-feel de uma apresentação mas não oferece as facilidades para
troca de objetos multimídia oferecida por MHEG.
• MHEG oferece mecanismos eficientes para a troca de documentos multimídia em
forma final. Estes mecanismos são bastantes genéricos mas caso seja necessário
definir exatamente como o documento deve ser apresentado, MHEG pode se provar
inadequado. Se os documentos são criados para serem navegados (browsed) os
mecanismos de MHEG não apenas poderosos mas flexíveis também de modo a
Página 48
Padrões para troca de documentos hipermídia
permitir customizações locais onde o leitor pode especificar como os componentes
estruturais devem ser apresentados. Este é o enfoque adotado pela WWW com
sucesso.
• HyTime, em parte por ser um padrão mais maduro que os anteriores proporciona os
mecanismos mais genéricos para autoria de multimídia. HyTime possui mecanismos
mais genéricos para a manipulação de tempo e espaço (através das batutas e varas
de condão) que os existentes nos outros padrões. No entanto, devido a estas
flexibilidades é muito difícil a implementação de uma máquina HyTime eficiente.
APLICAÇÕES
MODELAGEM
Máquina
MHEG
Máquina
HyTime
PREMO
Nível de apresentação
de PREMO
Hardware
Figura 27 Relacionamento entre HyTime, MHEG e PREMO
Uma forma possível de interação entre os padrões é através do uso de ferramentas
de autoria baseadas em HyTime e que explorem a sua flexibilidade e alto nível de
abstração. O resultado da processo de autoria seria convertido em objetos MHEG que
podem ser eficientemente transmitidos e apresentados através de uma máquina cuja
implementação é baseada em PREMO.
Uma outra alternativa, é a utilização de Java [Sun, 1996] para a implemetação da
máquina MHEG. Java está se tornando o padrão “de facto” para aplicações da WWW e já
existem sugestões para a integração da máquina virtual de Java com MHEG 5.
Página 48
Padrões para troca de documentos hipermídia
5. Referências
[Adie, 1994]
C. Adie. Network Access to Multimedia Information. Request for
Comments (RFC) 1614, Maio 1994.
[Apple, 1993]
Apple Corporation.Inside Macintosh: QuickTime, Apple Technical
Library. Addison Wesley Publishing Company, 1993.
[Barry, 1994]
Jeff Barry. The HyperText Markup Language (HTML) and the World
Wide Web: Raising ASCII Text to a New Level of Usability The PublicAccess Computer Systems Review 5, 5(5):5–62, 1994.
[Berners-Lee, 1993] Dick C. A. Bulterman. Retrieving (JPEG) Pictures in Portable
Hypermedia Documents. Em Tat-Seng Chua and Tosiyasu L. Kunii,
editor, Multimedia Modeling, páginas 217–226. World Scientific,
Novembro 1993. Proceedings da The First International Conference on
Multi-Media Modeling.
[Brown, 1989]
Heather Brown. Standards for Structured Documents. The Computer
Journal, 32(6):505–514, 1989.
[Buford, 1994]
John F. Koegel Buford. Multimedia Systems. Prentice Hall, 1994.
[Bulterman et al., 1991] Dick C. A. Bulterman. Retrieving (JPEG) Pictures Em Portable
Hypermedia Documents. Em Tat-Seng Chua and Tosiyasu L. Kunii,
editor, Multimedia Modeling, páginas 217–226. World Scientific,
Novembro 1991. Proceedings of the First International Conference on
Multi-Media Modeling.
[Casey1994]
Thomas Casey. MHEG, Scripts, and Standardisation Issues. Em
Wolfgand Hersnrer and Frank Kappe, editores, Multimedia/Hypermedia
Em Open Distributed Environments (Proceedings of the Eurographics
Symposium), páginas 29–43, Graz, Austria, June 1994.
[CCITT, 1988] CCITT. Recommendation X.500: The Directory — Overview of
Concepts, Models and Service. International Telecommunications
Union, Place des Nations 1211 Geneva, Switzerland, 1988.
[Colaitis e Bertrand1994] Colaitis and F. Bertrand. The MHEG Standard: Principles and
Examples of Applications. Em Wolfgand Hersnrer and Frank Kappe,
editores, Multimedia/Hypermedia Em Open Distributed Environments
(Proceedings of the Eurographics Symposium), páginas 3–17, Graz,
Austria, Junho 1994.
[Focus, 1996]
GMD Fokus. Fokus Home Page. http://www.focus.gmd.de.
[Fokus, 1995]
GMD Fokus. GLASS - Globally Accessible ServiceS — An Interactive
Distributed Multimedia Presentation System. Disponível em URL:
http://www.focus.gmd.de/ovma, 1995.
Página 48
Padrões para troca de documentos hipermídia
[Fujitsu and TechnoTeacher, 1995] Open Systems Solutions Fujitsu and TechnoTeacher
Inc. HyTime Application Development Guide, Maio 1995.
[Goldfarb, 1990] The SGML Handbook. Clarendon Press, 1990.
[Hardman et al., 1993] Lynda Hardman, Dick C. A. Bulterman, e Guido van Rossum.The
Amsterdam Hypermedia Model: Extending Hypertext to Support Real
Multimedia . Hypermedia, 5(1):47–69, 1993.
[Hardman et al., 1994] Lynda Hardman, Dick C. A. Bulterman, and Guido van Rossum.
The Amsterdam Hypermedia Model: Adding Time e Context to the
Dexter Model. Communications of the ACM, 37(2):50–63, Feb 1994.
[Herman et al., 1994] I. Herman, G. S. Carsonn, J. Davy, D. A. Duce, P. J. W. ten Hagen,
W. T. Hewitt, K. Kansy, B. J. Lurvey, R. Puk, G. J. Reynolds, e H.
Stenzel. PREMO: An ISO Standard for a Presentation Environment for
Multimedia Objects. Em Proceedings of the ACM Multimedia'94
Conference. ACM Press, Oct 1994. Disponível por anonymous ftp.
[ISO, 1986a]
ISO. ISO-8879: Formal Public Identifiers, 1986.
[ISO, 1988]
ISO. ISO 9069 Information Processing — SGML Support Facilities —
SGML Document Interchange Format (SDIF), Sep 1988.
[ISO, 1989]
ISO. ISO 8613 Information Processing - Text and Office Systems Office Document Architecture (ODA) and Interchange Format. 1989.
[ISO, 1992]
ISO. ISO/IEC DIS 10744 Information Technology
Hypermedia/Time-Based Structuring Language (HyTime), 1992.
[ISO, 1994a]
ISO. Information Processing Systems — Computer Graphics and
ImageProcessing — Presentation Environments for Multimedia Objects
(PREMO) ISO/IEC JTC1/SC24 Comittee Draft 14478-4.1, Julho 1994
Part 1: Fundamentals of Premo.
[ISO, 1994b]
ISO. PREMO Multimedia Systems Services Working Draft ISO/IEC
14478-4.2/199x(E), 1994. Second Draft setembro 1994.
—
[Koegel at all., 1993] John Koegel, Lloyd W. Rutledge, John L. Rutledge, and Can
Keskin. HyOctane: A HyTime Engine for an MMIS. In Proceedings of
ACM Multimedia 93, Aug 1993. Disponível por ftp anônimo.
[Leggett e Schnase, 1994] John J. Leggett e John L. Schnase. Viewing Dexter with Open
Eyes. Communications of the ACM, 37(2):76–86, Fevereiro 1994.
Editado por Kaj Gronbaek e Randall H. Trigg.
[Markey 1991]
Brian D. Markey. Emerging Hypermedia Standards - Hypermedia
Marketplace Prepares for HyTime and MHEG Em Usenix Summer
Conference Proceedings, páginas 59–74, Nashville, Tenessee, junho
1991.
[Meyer-Boudnik e Effelsberg1995] Thomas Meyer-Boudnik and Wolfgang Effelsberg.
MHEG Explained. IEEE Multimedia, 2(1):26–38, 1995.
Página 48
Padrões para troca de documentos hipermídia
[MHEG,1995b] Multimedia and Hypermedia Information Coding Expert Group MHEG
International Standard ISO/IEC DIS 13522-1 — Information
Technology - Coding of Multimedia and Hypermedia Information
Objects - Part 5: MHEG Subset for Base Level Implementation.
Technical report, ISO/IEC JTC1/SC29/WG12, Agosto 1995. Working
Draft 13522-5.
[MHEG,1995c] Multimedia and Hypermedia Information Coding Expert Group MHEG
International Standard ISO/IEC DIS 13522-1 — Information
Technology - Coding of Multimedia and Hypermedia Information
Objects - Part 5: MHEG Subset for Base Level Implementation.
Technical report, ISO/IEC JTC1/SC29/WG12, Dezembro 1995. Draft
of International Standard 13522-5.
[Newcomb at al., 1991] Steven R. Newcomb, Neil A. Kipp, e Victoria T. Newcomb. The
``HyTime'' Hypermedia/Time-based Document Structuring Language.
Communications of the ACM, 34(11):67–82, Novembro 1991.
[Newcomb, 1991] Steven R. Newcomb. Standard Music Description Language complies
with hypermedia standard. IEEE Computer, 24(7):76–79, July 1991.
[Ragget, 1993a] David Raggett. HTML+ (Hypertext markup format). Internet Draft
disponível em URL: ftp: //ftp.nisc.sri.com/draftragget-www-html-00.ps, Julho 1993.
[Ragget, 1993b] David Raggett. HTML+ (Hypertext markup language). A proposed
standard for light weight presentation independentdelivery format for
browsing and querying information across the Internet, Julho 1993.
[Raggett, 1994a] David Raggett A Review of the HTML+ Document Format. Em
Proceedings of the First International Conference on the World-Wide
Web (W3). Elsevier Science, 1994. Também disponível em
http://www1.cern.ch/Papers/WWW94/dsr.ps.
[Stenzel et al.,1994] H. Stenzel, G. S. Carson, I. Herman, and K. Kansy.PREMO: An
Architecture for Presentation of Multimedia Objects in an Open
Environment. Em Wolfgand Hersnrer e Frank Kappe, editores,
Multimedia/Hypermedia
in
Open
Distributed
Environments
(Proceedings of the Eurographics Symposium), páginas 77–96, Graz,
Austria, Junho 1994.
[Sun, 1996]
Sun Microsystems. Java Home Page em http://java.sun.com.
[van Herwijnen, 1994] Eric van Herwijnen. Pratical SGML. Kluer Academic Publishers,
1994.
Página 48