X-SMIL: Aumentando Reuso e Expressividade em Linguagens de Autoria Hipermídia
D ISSERTAÇÃO DE M ESTRADO
D EPARTAMENTO DE I NFORMÁTICA
Programa de Pós-Graduação em Informática
Rio de Janeiro
Abril de 2005
X-SMIL: Aumentando Reuso e Expressividade em Linguagens de Autoria Hipermídia
Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo Programa de Pós- Graduação em Informática da PUC-Rio.
Orientadore: Luiz Fernando Gomes Soares Co-orientador: Rogério Ferreira Rodrigues
Rio de Janeiro, abril de 2005
X-SMIL: Aumentando Reuso e Expressividade em Linguagens de Autoria Hipermídia
Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo Programa de Pós- Graduação em Informática da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada.
Luiz Fernando Gomes Soares Orientador Departamento de Informática - PUC-Rio
Rogério Ferreira Rodrigues Co-orientador Departamento de Informática - PUC-Rio
Marco Antonio Casanova Departamento de Informática - PUC-Rio
Renato Fontoura de Gusmão Cerqueira Departamento de Informática - PUC-Rio
José Eugenio Leal Coordenador Setorial do Centro Técnico Científico - PUC-Rio
Rio de Janeiro, 4 de abril de 2005
autor e do orientador.
Heron Vilela de Oliveira e Silva Formou-se em Engenheira de Computação pela PUC-Rio em 2002. Atualmente, integra o grupo de pesquisadores do Laboratório TeleMídia da PUC-Rio, desenvolvendo pesquisa na área de Sistemas Hipermídia.
Ficha Catalográfica Silva, Heron Vilela de Oliveira e
X-SMIL: aumentando reuso e expressividade em linguagens de autoria hipermídia / Heron Vilela de Oliveira e Silva ; orientador: Luiz Fernando Gomes Soares. – Rio de Janeiro : PUC-Rio, Departamento de Informática, 2005.
210 f. : il. ; 30 cm
Dissertação (mestrado) – Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática .
Inclui referências bibliográficas
1. Informática – Teses. 2. Sistemas hipermídia. 3.
Autoria. 4. Linguagens declarativas. 5 Relações. 6. SMIL.
7. Sincronização. 8. Conectores. 9. Templates. 10. NCL. I.
Soares, Luiz Fernando Gomes. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática.
III. Título.
CDD: 004
À Deus, por ser.
À minha família, pelo amor incondicional.
Aos meus orientadores, pela amizade, compreensão e apoio constante.
Aos amigos, por estarem, mesmo quando ausentes, sempre presentes.
Ao espírito TeleMídia.
Ao DI.
À PUC, CAPES, CNPq e FUNTTEL.
Silva, Heron Vilela de Oliveira. X-SMIL: Aumentando Reuso e Expressividade em Linguagens de Autoria Hipermídia. Rio de Janeiro, 2005. xxxp. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.
Este trabalho está inserido no contexto de ambientes de autoria e execução hipermídia, sendo as linguagens declarativas para autoria de documentos o seu foco principal. Tendo-se como objetivo aumentar a expressividade e o reuso na especificação de documentos hipermídia, este trabalho introduz as linguagens X- SMIL e NCL - Nested Context Language - versão 2.1. Utilizando-se o conceito de templates, X-SMIL permite a definição de novas semânticas para composições SMIL, além dos tradicionais elementos seq, par e excl. Templates, em X-SMIL, são especificados em um perfil de XTemplate, que estende a idéia original da linguagem XTemplate de NCL. Com base nas novas facilidades para definição de templates, esse perfil foi usado para especificar a linguagem NCL 2.1. X-SMIL também permite a especificação de conectores hipermídia, tratando relações hipermídia como entidades de primeira classe - funcionalidade incorporada em X- SMIL pelo uso do módulo XConnector de NCL. Outro objetivo deste trabalho é o de apresentar um framework para o processamento de documentos XML.
Utilizando-se esse framework, diversos compiladores foram implementados, o que possibilitou, entre outras funcionalidades, a conversão de documentos NCL em especificações SMIL ou X-SMIL e vice-versa.
Palavras-chave
sistemas hipermídia; autoria; linguagens declarativas; relações; elos;
sincronização; conectores; templates; NCL; SMIL; XML; compilador
Silva, Heron Vilela de Oliveira. X-SMIL: Improving Reuse and Expressiveness in Hypermedia Authoring Languages. Rio de Janeiro, 2005. XXXp. Master Thesis - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.
This work is related to hypermedia authoring and execution environments, and its main focus is declarative document authoring. Aiming at improving the expressiveness and reuse in the specification of hypermedia documents, this work introduces the hypermedia authoring languages X-SMIL and NCL - Nested Context Language - version 2.1. Exploiting the concept of templates, X-SMIL allows the definition of new semantics for SMIL compositions, besides its usual seq, par and excl elements. X-SMIL templates are specified using an XTemplate profile, which extends the original idea of the NCL XTemplate language.
Bringing new facilities for template definitions, this new profile is used to further improve the NCL language. X-SMIL also offers support for handling hypermedia relations as first-class entities, through the use of hypermedia connectors - brought to X-SMIL via the NCL XConnector module. Another important goal of this work is to present a framework to facilitate the development of XML documents parsing and processing tools. Based on this framework, several compilers were implemented, permitting, among other features, the conversion of NCL documents into SMIL or X-SMIL specifications and vice-versa.
Palavras-chave
hypermedia systems; authoring; declarative languages; relations; links;
synchronization; connectors; templates; NCL; SMIL; XML; compiler
1 Introdução 15
1.1. Motivação 15
1.2. Objetivos 19
1.3. Organização da Dissertação 22
2 Linguagens para Descrição de Documentos Hipermídia 23
2.1. SGML e XML 24
2.2. HTML e XHTML 26
2.3. SMIL 27
2.4. NCL 29
3 Nested Context Language 2.1 34
3.1. Funções de Custo 34
3.2. Regras de Apresentação 36
3.3. Refinamentos de NCL 2.1 40
3.4. Linguagem XConnector 46
3.5. Linguagem XTemplate 51
4 X-SMIL 64
4.1. XT-SMIL: SMIL + XTemplate 64
4.2. SMIL + XConnector (XC-SMIL) e X-SMIL 70
5 Framework para Compiladores 74
5.1. Framework Genérico para Processamento 76 5.2. Framework para Compiladores de Documentos NCL 85 5.2.1. Funcionamento do Framework de Compiladores NCL 86
5.2.2. Compiladores de documentos NCL 89
5.3. Framework para Compiladores de Documentos SMIL 93
5.4. X-SMIL 95
6 Trabalhos Relacionados 107
6.1. Template de Composição 107
6.2. Processamento de documentos XML 110
6.3. Framework e Compiladores 112
6.4. Compiladores XML 117
6.5. Extensões à SMIL 118
6.6. Conversão entre Modelos 120
7 Conclusão e Trabalhos Futuros 123
7.1. Templates 124
7.2. Conversões entre Formatos 127
8 Referências Bibliográficas 130
9 Apêndice A 136
9.1. NCL 2.0 136
9.2. NCL 2.1 138
10 Apêndice B 142
10.1. NCL21.xsd 142
10.2. NCL-AttributeInterface.xsd 144
10.3. NCL-BasicComposite.xsd 144
10.4. NCL-BasicDescriptor.xsd 145
10.5. NCL-BasicLayout.xsd 145
10.6. NCL-BasicMedia.xsd 146
10.7. NCL-BasicTiming.xsd 147
10.8. NCL-component.xsd 147
10.9. NCL-CompositeConnector.xsd 148
10.10. NCL-CompositeDescriptor.xsd 149
10.11. NCL-CompositeInterface.xsd 149
10.12. NCL-compositeTemplate.xsd 150
10.13. NCL-connector.xsd 150
10.16. NCL-CostFunction.xsd 153
10.17. NCL-DescriptorControl.xsd 154
10.18. NCL-interface.xsd 154
10.19. NCL-Language.xsd 157
10.20. NCL-layout.xsd 172
10.21. NCL-link.xsd 174
10.22. NCL-Linking.xsd 175
10.23. NCL-MediaInterface.xsd 176
10.24. NCL-presentation.xsd 177
10.25. NCL-struct.xsd 178
10.26. NCL-Structure.xsd 179
10.27. NCL-SwitchInterface.xsd 179
10.28. NCL-TestRules.xsd 180
10.29. NCL-timing.xsd 180
10.30. NCL-XTemplateUse.xsd 182
11 Apêndice C 183
11.1. XConnector21.xsd 183
12 Apêndice D 195
12.1. XT-BasicContraints.xsd 195
12.2. XT-BasicLinking.xsd 195
12.3. XT-BasicResources.xsd 196
12.4. XT-BasicVocabulary.xsd 197
12.5. XT-connector.xsd 197
12.6. XT-ConnectorVocabulary.xsd 198
12.7. XT-constraints.xsd 198
12.8. XTemplate21.xsd 199
12.9. XT-language.xsd 200
12.10. XT-linking.xsd 206
12.11. XT-resources.xsd 207
12.12. XT-struct.xsd 207
Figura 1:1. Subsistemas de um sistema hipermídia 16
Figura 2:1 - Aplicação SGML. 25
Figura 2:2 - Exemplo de um documento SMIL. 29 Figura 2:3 - Exemplo de um documento NCL. 30 Figura 2:4 - Exemplo de elos NCL e de reuso de conectores. 31 Figura 2:5 - Exemplo do uso de templates de composição. 33 Figura 3:1 - Exemplo de funções de custo em NCL 2.1. 35 Figura 3:2 - Exemplo de um nó switch em NCL 2.0 37 Figura 3:3 - Exemplo de regras de apresentação e nó switch em NCL 2.1.39 Figura 3:4 - Exemplo de documento NCL 2.1. 42 Figura 3:5 - Switch de conteúdo e de descritores. 44 Figura 3:6 - Máquina de estados de um evento. 47 Figura 3:7 - Exemplos de conectores em NCL 2.0. 49 Figura 3:8 - Relações finishes e overlaps. 49 Figura 3:9 - Exemplo de conectores em NCL 2.1. 50 Figura 3:10 - Exemplo de template de composição em NCL 2.0. 53 Figura 3:11 - Visão temporal de uma composição NCL. 53 Figura 3:12 - Exemplo de template de composição em NCL 2.1. 59 Figura 3:13 - Visão temporal de uma composição NCL. 60 Figura 3:14 - Exemplo de template com relações de inclusão e por
conectores em NCL 2.1. 61
Figura 4:1 - Visão temporal de uma composição par em SMIL. 66 Figura 4:2 - Visão estrutural de uma composição XT-SMIL par antes e
após o processamento de template. 66
Figura 4:3 - Template audioComLegendasEnPt em XT-SMIL. 68 Figura 4:4 - Composição XT-SMIL par utilizando um template. 70 Figura 4:5 - Resultado do processamento de template em uma
composição XT-SMIL par. 70
Figura 4:6 - Exemplo de elo em uma composição SMIL. 71
Figura 4:9 - Exemplo de uma composição X-SMIL. 73 Figura 5:1 - . Visão geral da estruturação em dois níveis dos frameworks para compiladores de linguagens modulares. 78 Figura 5:2 - Exemplo de um método do tipo parse de um framework de
compiladores. 81
Figura 5:3 - Diagrama de classes do gerador automático de frameworks
de compiladores. 83
Figura 5:4 - Diagrama de classes do framework para compiladores NCL.86 Figura 5:5 - Exemplo simplificado de documento NCL. 87
Figura 5:6 - Compiladores NCL. 90
Figura 5:7 - Composição SMIL gerada a partir do compilador NCL-SMIL.92 Figura 5:8 - Diagrama de classes do Framework para Compiladores SMIL.9 Figura 5:9 - Processador de Template XTemplate 2.1. 97 Figura 5:10 - Documento XML com a cópia de uma composição sendo
processada. 98
Figura 5:11 - Composição gerada pelo processador de templates. 99 Figura 5:12 - Exemplo de transformada body XSLT. 101 Figura 5:13 - Exemplo de transformada link XSLT. 104 Figura 5:14 - Exemplo de transformada constraint XSLT. 105 Figura 6:1 - Exemplo de um documento representando um noticiário no
sistema LAMP. 108
Figura 6:2 - Template para artigos de um noticiário. 109
Figura 6:3 - API DOM de JAXP. 110
Figura 6:4 - API SAX de JAXP. 111
Figura 6:5 - Ferramentas XANTLR e TDOM. 114
Figura 6:6 - Especificação da classe FirstApplet em Java. 115 Figura 6:7 - Especificação de FirstApplet em JavaML. 116 Figura 6:8 - Framework XVM para o desenvolvimento de aplicações com
XML. 117
Figura 6:9 - Edição de um documento em timeline. 121
Tabela 1 - Elementos do módulo CostFunctions. 35 Tabela 2 - Elementos do módulo TestRules. 38 Tabela 3 - Diferenças entre NCL 2.1 e NCL 2.0. 46 Tabela 4 - Nomes das transições para a máquina de estados de um
evento. 47
Tabela 5 - Elementos da linguagem XTemplate de NCL 2.0. 52 Tabela 6 - Elementos da linguagem XTemplate de NCL 2.1. 56
Tabela 7 - Tabela de Elementos. 77
Tabela 8 - Tabela de Grupos de Elementos. 77
Tabela 9 - Tabela de Áreas Funcionais. 77
1
Introdução
Em sua origem, a WWW - World-Wide Web (Berners-Lee, 1994) foi concebida como uma aplicação de hipertexto, visando apresentar informações científicas com referências cruzadas e permitindo a pesquisa automática de textos.
Para especificação de documentos nessa aplicação, foi definida a primeira versão da linguagem HTML, que veio a se tornar um padrão do W3C Consortium
1. Universalmente adotada nos dias atuais, HTML (W3C, 1999a) é a principal linguagem para a autoria de documentos na rede mundial de computadores.
O fenômeno de difusão da Internet ultrapassou todas as previsões e o paradigma de hipertexto, utilizado pela linguagem HTML em sua forma original, evoluiu para o paradigma hipermídia. Proporcionando a incorporação de novos formatos de mídia, o paradigma hipermídia traz também novos requisitos, como a definição de sincronismo temporal e espacial entre componentes de um documento. Tais requisitos vêm motivando uma extensa pesquisa na área de sistemas hipermídia, acarretando a definição de novos padrões, tanto para a WWW como para outros sistemas.
Contextualizando o trabalho, este capítulo apresenta, inicialmente, uma visão geral de sistemas hipermídia e conceitos relacionados. Baseados nesses conceitos, serão apontados a motivação e os objetivos desta dissertação.
Finalmente, a organização do restante do texto é apresentada.
1.1.
Motivação
Um sistema hipermídia possui, tipicamente, os seguintes subsistemas
2: o de autoria (edição), o de armazenamento e o de execução (exibição). Durante o
1
http://www.w3c.org/
2
Os subsistemas também podem ser chamados de ambientes ou módulos do sistema
hipermídia.
processo de autoria, o sistema deve oferecer ferramentas que possibilitem especificar um documento hipermídia de acordo com as concepções do autor.
Essa especificação pode, então, tanto ser armazenada quanto entregue para exibição. A Figura 1:1 ilustra os subsistemas de um sistema hipermídia.
Autor
Autoria
Gráfica
Declarativa
Objetos Hipermídia
Armazenamento Execução
Formatador &
Ferramentas de Exibição Usuários &
Dispositivos de E/S
Autor
Autoria
Gráfica
Declarativa
Objetos Hipermídia
Armazenamento Execução
Formatador &
Ferramentas de Exibição Usuários &
Dispositivos de E/S
Figura 1:1. Subsistemas de um sistema hipermídia
O subsistema de autoria deve fornecer os recursos necessários para que um autor (ou autores) especifique um documento hipermídia. Nesse subsistema, é desejável a presença de ferramentas de autoria seguindo tanto o paradigma gráfico (baseado em interfaces gráficas) quanto o paradigma declarativo (baseado em linguagens textuais) - como apresentado em (Coelho, 2004).
O subsistema de armazenamento é responsável pelo armazenamento,
recuperação e, em certos casos, adaptação de documentos
3. Em geral, os dados
armazenados são classificados em descrição dos documentos (contendo
informações a respeito da estrutura do documento, os relacionamentos entre seus
componentes e especificações de apresentação) e conteúdo dos objetos de mídia
(arquivos de texto, imagem, áudio, vídeo etc. referenciados pela descrição dos
documentos). Um dos formatos possíveis para o armazenamento das descrições de
documentos é a especificação em uma linguagem declarativa.
Finalmente, o subsistema de execução (ou de apresentação) contém os mecanismos para interagir com os usuários e controlar a exibição dos objetos de mídia, de forma a respeitar as especificações do documento. Entre os elementos que compõem o ambiente de execução, podem ser destacados: as ferramentas de exibição e o formatador hipermídia. As ferramentas de exibição são compostas pelos recursos de hardware ou software responsáveis por tratar os dispositivos de entrada e saída (Dispositivos de E/S na Figura 1:1), controlando a exibição do conteúdo dos objetos e a interação com o(s) usuário(s). O formatador hipermídia é o nome dado ao elemento que reúne as funções para o controle da apresentação.
Para realizar suas tarefas, o formatador deve receber a especificação de um documento que, como já mencionado, pode ser baseada em uma linguagem declarativa.
A adaptação de documentos é uma funcionalidade desejável em sistemas hipermídia. Seja no subsistema de armazenamento ou no de execução, a adaptação de documentos pode atuar sobre a estrutura, apresentação ou o próprio conteúdo dos objetos. Essa adaptação pode ser direcionada pelas características da plataforma de armazenamento (capacidade de processamento disponível, banda passante disponível para o acesso aos recursos gravados em memória secundária, número de clientes conectados, banda passante para transmissão dos dados no sistema de comunicação etc.) e, também, pelas informações provenientes do ambiente de execução (preferências e conhecimentos do usuário, recursos de hardware disponíveis na plataforma de exibição, localização etc.). Todas essas informações fazem parte do contexto de apresentação do documento (Boll & Klas, 1999; Brusilovsky, 1996; Dey et al., 2001; Schilit et al., 1994; Villard et al., 2000). Dessa forma, é desejável que linguagens declarativas hipermídia ofereçam suporte à criação de documentos adaptáveis.
Esta dissertação tem como foco linguagens para autoria declarativa de documentos hipermídia. A expressividade dessas linguagens está diretamente relacionada com o modelo hipermídia no qual elas se baseiam. Analisando os diversos modelos hipermídia propostos na literatura, podem ser observadas duas entidades básicas: nós (representando componentes de conteúdo de um documento) e elos (representando relacionamentos entre nós) (Muchaluat-Saade,
3
O conceito de adaptação será detalhado posteriormente.
2003). Freqüentemente, uma terceira entidade também é encontrada, chamada nó de composição, ou simplesmente composição. Assim como elos, nós de composição são utilizados para representar relacionamentos entre componentes de um documento. Visando um aumento de expressividade (dentre outros benefícios), modelos mais complexos possuem outras entidades. A complexidade e o poder de expressão dos modelos são, obviamente, herdados por suas linguagens.
Com o surgimento do padrão XML (W3C, 2000b), linguagens declarativas, nele baseadas (aplicações XML), foram definidas para diferentes modelos hipermídia. O modelo hipermídia CMIF (van-Rossum et al., 1993), por exemplo, serviu como base para a linguagem Synchronized Multimedia Integration Language - SMIL (W3C, 2001b), enquanto o modelo Nested Context Model - NCM (Soares et al., 2003) originou a linguagem Nested Context Language - NCL (Muchaluat-Saade et al., 2003; Muchaluat-Saade, 2003).
Comparando as diversas linguagens hipermídia existentes, podem ser observadas características e funcionalidades presentes somente em algumas delas.
Isso ocorre com NCL, por exemplo, que possui o conceito de conectores hipermídia e de templates de composição - conceitos não encontrados em outras linguagens hipermídia. Conectores hipermídia (definidos pela linguagem XConnector de NCL) são entidades que expressam a semântica de uma relação, podendo ser reutilizados para criação de diferentes relacionamentos (elos).
Templates de composição (definidos pela linguagem XTemplate de NCL
4), por sua vez, especificam a semântica de composições (semântica temporal paralela, semântica temporal seqüencial etc.), podendo ser reaproveitados por diferentes composições, que herdam as especificações definidas no template.
Diferente de NCL, composições SMIL possuem uma semântica temporal pré-definida (seqüencial, paralela etc.). Em diversos casos, as composições com semântica temporal em SMIL oferecem uma grande facilidade para autoria de documentos. Entretanto, a facilidade de autoria oferecida está restrita ao uso das composições previamente definidas pela linguagem. Além das composições, um número limitado de eventos podem ser utilizados para definição de elos
4
As linguagens XConnector e XTemplate fazem parte do conjunto de especificações da
linguagem NCL.
(relacionamentos) entre nós. Porém, na especificação de relacionamentos complexos, é necessária a combinação de diversos eventos e/ou composições SMIL. Essa abordagem dificulta o processo de autoria e, principalmente, o reuso.
Visando aumentar o reuso e facilitar ainda mais o processo de autoria, é interessante incorporar o conceito de conectores e templates hipermídia à linguagem SMIL. Conectores podem definir relações simples ou complexas, e permitem que qualquer relacionamento SMIL (tanto via composições, como via eventos) seja declarado da mesma maneira: através do reuso de conectores. O uso de templates de composição possibilita a definição de diferentes semânticas para composições, criando, dessa forma, um mecanismo para tornar SMIL extensível em relação às composições que oferece.
Este trabalho engloba não apenas a expressividade e facilidade de reuso em linguagens hipermídia (notadamente: NCL e SMIL), mas também a conversão (interoperabilidade) entre os diversos formatos abstratos por elas gerados. Assim, por exemplo, um documento SMIL pode ser editado em um ambiente de autoria utilizando-se de um outro formato de dados (como objetos Java de uma implementação do modelo NCM). De forma análoga, para que esse documento seja enviado para o subsistema de armazenamento, pode ser necessária sua conversão para um outro formato. Finalmente, para sua apresentação, pode ser ainda exigida uma conversão para o formato de dados do formatador hipermídia que irá exibi-lo. Essas conversões são realizadas por compiladores de documentos de linguagens hipermídia, como será apresentado.
1.2.
Objetivos
Os dois principais objetivos desta dissertação são: (1) aumentar o reuso e a
expressividade da linguagem SMIL, especificando a linguagem X-SMIL; e (2)
definir frameworks de compiladores e implementar suas instâncias (compiladores
específicos) para processar documentos nessas linguagens. Como decorrência
desses objetivos, um terceiro surge naturalmente para viabilizá-los: (3) o
refinamento da linguagem NCL, introduzindo a versão 2.1 dessa linguagem - que
estende sua versão anterior (2.0).
Assim, inicialmente, o refinamento à linguagem NCL será proposto. Entre as principais melhoras destacam-se a definição de um módulo
5NCL para a especificação de funções de custo para as durações de objetos de mídia (Rodrigues, 2003) e a definição de um módulo para a especificação de regras de apresentação, buscando auxiliar a autoria de documentos adaptativos. A maior contribuição nesse refinamento, no entanto, é a redefinição da linguagem XTemplate de NCL, utilizada para a especificação de templates de composição.
A proposta para a extensão de SMIL será desenvolvida introduzindo, nessa linguagem, o conceito de templates de composição e o conceito de conectores.
Dessa forma, uma nova linguagem, chamada X-SMIL, é especificada. Em X- SMIL serão permitidos: a definição e reuso de especificações semânticas para composições - através de templates de composição; e a definição e reuso de especificações de relações - através de conectores (que podem ser entendidos, nesse contexto, como templates para elos).
Na definição da linguagem X-SMIL, adotou-se uma estratégia para incorporação dos conceitos mais importantes de NCL. Assim, a linguagem X- SMIL é definida por meio de duas extensões à linguagem SMIL: o perfil
6SMIL + XTemplate (ou XT-SMIL), que introduz as diversas vantagens do uso de templates de composição em SMIL; e o perfil SMIL + XConnector (ou XC- SMIL), que incorpora o conceito de conectores (e a definição de elos a partir de referências a conectores) à linguagem SMIL.
Apesar de a linguagem XTemplate de NCL permitir relacionamentos outros que não apenas aqueles definidos por conectores, a versão XTemplate de NCL 2.0 (ou, simplesmente, XTemplate 2.0) era limitada a esses relacionamentos. Como, a princípio, no perfil XT-SMIL não seria viável a utilização de templates de composição sem o uso de conectores, foi preciso redefinir a linguagem XTemplate 2.0, dando origem à linguagem XTemplate 2.1. Essa redefinição consiste na sua estruturação em perfis, dependentes das relações para as quais provêem suporte. Um desses perfis, independente de conectores e que possibilita a
5
O conceito de módulos de linguagens será apresentado no Capítulo 2.
6
Perfis de linguagem reúnem um subconjunto dos módulos oferecidos pela linguagem,
definindo assim um subconjunto de funcionalidades apropriadas para a construção de uma
determinada classe de documentos.
definição de relações de inclusão, é o utilizado em XT-SMIL. Relações de inclusão
7constituem a forma mais simples de se introduzir o conceito de templates em SMIL.
A definição do perfil XC-SMIL é simples, pois XConnector é um módulo independente em NCL. Finalmente, é definida a linguagem X-SMIL, resultante da combinação de XT-SMIL e XC-SMIL. Em X-SMIL, o perfil de XTemplate 2.1 utilizado pode definir relações através de conectores ou relações de inclusão. Esse perfil de XTemplate é, exatamente, o definido pela linguagem NCL 2.1.
Como mencionado, um dos objetivos deste trabalho é a análise da interoperabilidade entre as linguagens NCL, SMIL e X-SMIL - através de compiladores de documentos de cada uma dessas linguagens para documentos nas outras duas. A compilação de documentos nessas três linguagens para uma implementação do modelo NCM em Java e para o modelo de execução do Formatador HyperProp (Rodrigues, 2003) também será abordada, com o objetivo de visualização gráfica, edição e execução (exibição) desses documentos no sistema HyperProp (Soares et al., 2000).
Como cada grupo de compiladores (de NCL, de SMIL e de X-SMIL) analisa documentos de uma mesma linguagem de origem, várias funcionalidades podem ser reaproveitadas e implementadas uma única vez. A identificação dessas funcionalidades constitui o primeiro passo de implementação, dando origem à definição de frameworks para compiladores, como o framework para compiladores NCL.
Além das características comuns aos compiladores de uma mesma linguagem, observou-se, em outro nível de abstração, aspectos comuns que podem ser reutilizados em processadores de qualquer linguagem baseada em XML. A partir dessas observações, uma estrutura em dois níveis para especificação de frameworks para implementação de compiladores é proposta. Em um primeiro nível, existe o framework genérico de processamento (ou meta-framework), cujo objetivo é facilitar o desenvolvimento de frameworks de compiladores. O meta- framework define, sintática e semanticamente, os métodos de frameworks de compiladores e a estruturação das classes desses frameworks (que são gerados
7
Relações de inclusão permitem especificar as composições nas quais determinados objetos
devem estar contidos.
automaticamente, a partir das especificações de linguagens baseadas em XML).
Dessa forma, o framework para compiladores NCL, o framework para compiladores SMIL e o framework para compiladores X-SMIL representam instâncias do meta-framework.
Finalmente, é importante destacar que, juntamente com a descrição desses compiladores, será apresentada a implementação do processador de template para os perfis da linguagem XTemplate. Esse processador também é implementado como instância do meta-framework de compiladores.
1.3.
Organização da Dissertação
Esta dissertação está estruturada da seguinte forma. O Capítulo 2 apresenta
linguagens para especificação de documentos hipermídia, dando destaque para as
linguagens NCL e SMIL. O Capítulo 3 discute as principais funcionalidades
introduzidas e refinadas na linguagem NCL. Nesse capítulo, são detalhados os
novos módulos de NCL: os novos módulos para templates de composição (ou
seja, a definição e estruturação da linguagem XTemplate 2.1), o módulo para
especificação de regras de apresentação, o módulo para especificação de funções
de custo e os refinamentos da linguagem XConnector. O Capítulo 4 contempla a
linguagem X-SMIL, detalhando os perfis que compõem essa linguagem: XT-
SMIL (SMIL + XTemplate) e XC-SMIL (SMIL + XConnector). O Capítulo 5
trata dos compiladores para linguagens XML, apresentando o meta-framework de
compiladores, assim como os frameworks para compiladores instanciados a partir
do meta-framework. O Capítulo 5 também descreve os compiladores instanciados
a partir dos frameworks para compiladores. O Capítulo 6 traz comparações com os
principais trabalhos relacionados da área e o Capítulo 7 tece as considerações
finais da dissertação, salientando as contribuições do trabalho e possíveis
pesquisas futuras.
2
Linguagens para Descrição de Documentos Hipermídia
Linguagens de programação podem ser classificadas de modos variados.
Uma classificação possível distingue as linguagens entre procedurais (imperativas) e declarativas. Linguagens procedurais exigem que o programador especifique, em detalhes, os passos que o programa deve executar para realizar a tarefa projetada (são escritas muitas linhas de código para indicar os passos exatos a fim de se obter um resultado). Em linguagens declarativas, por outro lado, o programador provê uma definição da tarefa a ser realizada, não estando preocupado com os detalhes de como o computador usará essa definição (é oferecida uma descrição exata do objetivo). Em outras palavras, a diferença entre linguagens procedurais e declarativas é que, na primeira, se especifica como obter a resposta, enquanto, na segunda, se especificam as condições que devem ser satisfeitas para se obter a resposta. Programação declarativa envolve o que deve ser computado, mas não necessariamente como será computado.
Embora linguagens procedurais possam ser utilizadas na autoria de documentos hipermídia (FLEXTV, 2004a), linguagens declarativas oferecem um nível mais elevado de abstração para a programação, por evitar que o programador (ou autor, no contexto de autoria de documentos) escreva muitos dos detalhes de execução que podem ser inferidos pelo interpretador. Esse interpretador (ou executor) é o elemento responsável por aplicar um algoritmo pré-definido às especificações feitas em uma linguagem declarativa para produzir o resultado almejado (como foi visto, esse elemento, em sistemas hipermídia, é denominado formatador). Assim, um programador declarativo experiente é qualificado para descrever cuidadosamente os resultados esperados, entretanto, mantém-se ignorante de como o código interno é executado para se obter o resultado.
Obviamente, a linguagem declarativa deve prover os recursos necessários para que o programador/autor seja capaz de especificar um programa/documento de acordo com sua concepção
8.
8
Uma comparação entre autoria declarativa e procedural, apontando suas vantagens e
desvantagens, pode ser consultada em (FLEXTV, 2004a).
Por apresentarem um nível de abstração mais elevado para a programação, esta dissertação irá tratar apenas de linguagens declarativas para autoria de documentos. Em especial, serão abordadas linguagens de marcação declarativas definidas utilizando o padrão XML.
Este capítulo está estruturado da seguinte maneira. Inicialmente discorre-se sobre a meta-linguagem SGML, padrão ISO (International Organization for Standardization
9) que estabeleceu o conceito de linguagens de marcação para autoria de documentos eletrônicos. Em seguida, é apresentada a meta-linguagem XML, um perfil SGML
10a partir do qual várias linguagens de marcação foram criadas e vêm sendo utilizadas nas mais diversas áreas. Finalmente, são descritas linguagens declarativas baseadas em XML voltadas para o domínio de autoria de documentos hipermídia, notadamente: XHTML, SMIL e NCL.
2.1.
SGML e XML
O padrão Standard Generalized Markup Language - SGML (ISO, 1986) permite a definição de documentos em função do domínio de aplicação a que se destinam. Marcações SGML permitem especificar a estruturação desses documentos, independente de como os mesmos devam ser apresentados. A formatação (ou seja, características de apresentação) de um documento SGML deve ser definida externamente ao documento, utilizando, por exemplo, tecnologias de folhas de estilos - como CSS (W3C, 1998a).
Para a definição e interpretação de um documento SGML, é preciso especificar uma gramática formal. Uma gramática SGML define como as marcações devem ser interpretadas, quais as regras que restringem o uso de cada marcação nos diferentes contextos do documento e, quando for relevante, a ordem dessas marcações no documento.
A Figura 2:1 ilustra uma aplicação SGML, composta por declarações SGML, uma DTD (Document Type Definition) e um interpretador. De maneira simplificada, declarações SGML definem um conjunto de regras de sintaxe para uma linguagem, enquanto a DTD especifica sua semântica. Dessa forma, uma
9
http://www.iso.org/
10
Como será apresentado, o conceito de perfil SMGL é distinto do conceito de perfil de
linguagem apresentado anteriormente.
aplicação SGML
11tem definida a gramática a ser seguida por documentos de uma linguagem, sendo possível aos interpretadores dessa aplicação, além de verificar a sintaxe desses documentos, também interpretar sua semântica, controlando, inclusive, suas exibições.
Documento
Declarações SGML DTD
Interpretador
Documento
Declarações SGML
Declarações SGML DTD DTD
Interpretador
Figura 2:1 - Aplicação SGML.
SGML é suficientemente formal para possibilitar a validação de documentos; tem estrutura suficiente para permitir a especificação e o manuseamento de documentos complexos; e possui mecanismos de extensão capazes de suportar a gestão de grandes repositórios de informação. Entretanto, dada a sua generalidade, a utilização direta de SGML mostrou-se demasiadamente complexa. Visando solucionar parte desse problema, foi definido o padrão XML:
um perfil SGML.
Extensible Markup Language - XML (W3C, 2004) restringe alguns dos pontos de flexibilização de SGML, facilitando o desenvolvimento de novas aplicações (linguagens de marcação), assim como o processamento e o intercâmbio de documentos declarados nessas linguagens. XML vem se mostrando um padrão de fato para criação de linguagens de marcação, tanto para domínios hipermídia quanto para outros domínios.
De maneira simplificada, XML é menos genérico que o padrão SGML, pois predefine as declarações SGML desse padrão (ver Figura 2:1). Assim, é necessária apenas a especificação de DTDs na criação de novas linguagens (aplicações XML). Devido a suas características, XML foi amplamente utilizado, levando à identificação não somente de suas diversas vantagens, mas, também, de algumas de suas limitações. A dificuldade no reuso das definições presentes nas DTDs, por exemplo, foi um dos fatores que impulsionou o desenvolvimento de
11
Uma aplicação SGML é constituída por um perfil SGML e por uma DTD específica. Ou
seja, um interpretador que possui somente declarações SGML constitui um perfil (profile) SGML.
novas tecnologias relacionadas a XML (W3C, 2001d; W3C, 1999b). Essas novas tecnologias oferecem uma funcionalidade de extrema importância quando se abordam linguagens de marcação baseadas em XML: a criação de linguagens seguindo uma abordagem modular. Módulos agrupam, de forma coerente, elementos e atributos XML
12que possuam alguma relação semântica entre si.
Diversas são as vantagens da definição de uma linguagem de forma modular. Um primeiro benefício é a possibilidade de criação de perfis de linguagem. Perfis reúnem um subconjunto dos módulos oferecidos pela linguagem, definindo, assim, um subconjunto de funcionalidades apropriadas para a construção de uma determinada classe de documentos. Outra vantagem da estruturação da linguagem em módulos é a facilidade de reutilização. Linguagens podem ser construídas definindo novos módulos e reusando módulos oferecidos por outras linguagens. Mais ainda, é possível a criação de novas linguagens XML através da simples combinação de diversos módulos já existentes em outras linguagens, sem a necessidade de definição de novos módulos. Essas várias vantagens possibilitam que cada linguagem, ou perfil da linguagem, atenda aos requisitos de uma determinada aplicação.
Outra vantagem da abordagem modular é a estruturação da linguagem, que pode ser extremamente útil em linguagens complexas (e com um grande número de elementos e atributos). Assim, módulos podem agrupar os elementos e atributos que possuam semântica relacionada, facilitando, entre outras coisas, a manutenção da linguagem. Como o número de módulos pode ser grande, algumas linguagens definem um segundo nível de estruturação, agrupando seus módulos em áreas funcionais.
2.2.
HTML e XHTML
HyperText Markup Language - HTML - é a principal linguagem utilizada para autoria de documentos na WWW. Tendo sua primeira versão publicada em 1992 (como uma aplicação SGML), HTML (W3C, 1999a) é, atualmente, uma linguagem declarativa de autoria padronizada pelo W3C.
12
Elementos e atributos XML serão exemplificados nas próximas subseções.
O modelo hipermídia que fundamenta a linguagem HTML é bastante simples, possibilitando a criação de uma linguagem de fácil autoria (apesar de limitar tanto seu poder de expressão quanto seus recursos para reuso). Páginas HTML representam os nós do modelo, enquanto elos definem os relacionamentos entre essas páginas. Elos HTML são sempre de referência (do tipo go-to) e possuem duas características principais: especificam um relacionamento entre uma única origem e um único destino; e são sempre definidos como parte do conteúdo dos nós (mais especificamente, como parte do conteúdo dos nós de origem do elo).
Essas características impedem a identificação dos elos que fazem referência a uma determinada página; não permitem a separação entre os dados sendo referenciados e as referências propriamente ditas (dificultando a manutenção dos dados e dos elos); não possibilitam a reutilização de nós sem a herança obrigatória dos relacionamentos (por exemplo, não é possível reusar uma página HTML sem herdar todos os seus elos); e impedem a definição de elos em páginas nas quais o autor não possua direitos de escrita.
Apesar das limitações de HTML, sua simplicidade proporcionou uma ampla utilização dessa linguagem. Assim, com a maturidade e simplicidade de HTML e o surgimento do padrão XML, observou-se a possibilidade de definir uma linguagem baseada em XML oferecendo todas as funcionalidades de HTML: a linguagem XHTML (W3C, 2000c). Dessa forma, XHTML possui todos os benefícios de XML (facilidade de intercâmbio de documentos entre aplicações;
facilidade na implementação de processadores de documentos nessa linguagem;
variedade de bibliotecas de software que oferecem suporte a XML; variedade de tecnologias aplicáveis a XML etc.) agregados à maturidade de HTML.
2.3.
SMIL
Synchronized Multimedia Integration Language - SMIL (W3C, 2001b) é
uma linguagem de marcação declarativa modular (estruturada em 10 áreas
funcionais), derivada de XML, para autoria de documentos hipermídia. Tendo
como foco relações de sincronismo temporal, SMIL é um padrão W3C que visa
incorporar esse requisito à WWW (ver Capítulo 1), de forma a superar as
limitações de HTML. Diferente de HTML, cujos elos somente possibilitam especificação de relacionamentos de referência entre páginas, SMIL também permite a definição de relacionamentos de sincronismo temporal. Esses relacionamentos são expressos por meio de eventos ou composições.
Composições SMIL contêm um conjunto de nós (objetos de mídia ou outros nós de composição) e possuem semântica temporal: a composição par determina que seus nós internos devem ser exibidos em paralelo; a composição seq determina a exibição de seus nós em seqüência; e a composição excl (exclusiva) especifica que seus nós não podem ser exibidos simultaneamente. Além de composições, relacionamentos em SMIL podem ser definidos através de eventos, como begin (início de apresentação), end (término de apresentação) e click (clique do mouse). A Figura 2:2 apresenta um documento SMIL simplificado. A composição seq definida nas linhas 08-18 especifica a exibição, em seqüência, de suas composições internas. A composição par (linhas 09-13) determina a exibição em paralelo de um vídeo, um áudio e uma imagem: video1, audio1 e img1. O elo da linha 12, definido juntamente com a imagem
13, especifica que a exibição dessa imagem deve terminar (atributo end) ao final da exibição de audio1 (valor do atributo end especificado como o evento audio1.end). A outra composição seq (linhas 14-17) determina que dois áudios sejam exibidos em seqüência. Pela semântica da composição seq mais externa, esses dois últimos áudios serão exibidos após o término da composição paralela.
01. <smil>
02. <head>
03. <layout>
04. ...
05. </layout>
06. </head>
07. <body id=" ">
08. <seq>
09. <par>
10. <video id="video1" />
11. <audio id="audio1" />
12. <img id="img1" end="audio1.end" />
13. </par>
14. <seq>
15. <audio id="audio2" />
13
O nó imagem é definido por meio do elemento XML img, enquanto o elo é definido
utilizando o atributo XML end desse elemento.
16. <audio id="audio3" />
17. </seq>
18. </seq>
19. </body>
20. </smil>
Figura 2:2 - Exemplo de um documento SMIL.
Visando incorporar à HTML as facilidades para autoria de documentos com sincronização temporal presentes em SMIL, foi proposta, em 1998, para padronização no W3C, a linguagem HTML+TIME (W3C, 1998c).
2.4.
NCL
Nested Context Language - NCL (Muchaluat-Saade et al., 2003; Muchaluat- Saade, 2003) é uma linguagem declarativa modular baseada em XML (e estruturada em 11 áreas funcionais) para especificação de documentos hipermídia.
Fazendo uso das funcionalidades XML já descritas, NCL reusou, sempre que possível, módulos definidos pela linguagem SMIL (Muchaluat-Saade, 2003).
Composições em NCL, assim como em SMIL, podem conter um conjunto de nós, que podem ser objetos de mídia ou outros nós de composição. Entretanto, em NCL, composições (elemento composite) não possuem semântica temporal, mas de inclusão e, conseqüentemente, sua semântica é dada por seus elos.
A Figura 2:3 mostra um exemplo de um documento NCL similar ao documento SMIL da Figura 2:2. Para se obter a semântica do documento SMIL, elos NCL devem ser especificados, sincronizando os nós de cada composição.
Esses elos NCL devem refletir a sincronização paralela e seqüencial das composições SMIL e também refletir o elo SMIL entre audio1 e img1. Elos NCL são definidos separadamente dos nós por eles relacionados, estando agrupados em bases de elos (elemento linkBase). Essa abordagem permite, por exemplo, o reuso de nós sem a herança obrigatória de elos. Outra opção para especificar esse documento NCL é através de atribuição semântica, no caso paralela ou seqüencial, a composições NCL. Como será visto, isso é possível através de templates de composição.
01. <ncl>
02. <head>
03. <layout>
04. ...
05. </layout>
06. ...
07. </head>
08. <body id=" ">
09. <composite>
10. <composite>
11. <video id="video1" />
12. <audio id="audio1" />
13. <img id="img1"/>
14. <linkBase>
15. ...
16. <link id="link1" xconnector="finishes.xml">
17. <bind component="audio1" role="on_x_presentation_end"/>
18. <bind component="img1" role="stop_y"/>
19. </link>
20. ...
21. </linkBase>
22. </composite>
23. <composite>
24. <audio id="audio2" />
25. <audio id="audio3" />
26. <linkBase>
27. ...
28. <link id="link2" xconnector="meets-start.xml">
29. <bind component="audio2" role="on_x_presentation_end"/>
30. <bind component="audio3" role="start_y"/>
31. </link>
32. ...
33. </linkBase>
34. </composite>
35. <linkBase>
36. ...
37. </linkBase>
38. </composite>
39. </body>
40. </ncl>
Figura 2:3 - Exemplo de um documento NCL.
Elos NCL são definidos através de conectores hipermídia. Um conector
especifica uma relação de forma independente do relacionamento, ou seja, não
especifica quais serão os nós relacionados. Elos que representam um mesmo tipo
de relação, mas que interligam nós distintos, podem reusar um mesmo conector
(aproveitando toda sua especificação). Um conector hipermídia especifica um
conjunto de pontos de interface, chamados papéis (roles). Para a criação de um
elo, faz-se referência a um conector e define-se um conjunto de binds, que
associam cada extremidade do elo (ponto de interface de um nó) a um papel do
conector. Conectores são especificados através da linguagem XConnector (Muchaluat-Saade, 2003) de NCL.
Na Figura 2:3 é possível observar a especificação de dois elos (por clareza, os demais elos do documento foram omitidos). O elo (elemento link) link1 define que, ao término de audio1, deve ser interrompida a apresentação de img1. Essa semântica é obtida por meio do conector especificado no documento finishes.xml, onde são declarados os papéis on_x_presentation_end e stop_y. Os elementos do tipo bind desse elo fazem a associação do áudio e da imagem com os papeis definidos pelo conector. Já o elo link2 define que audio3 deve ser iniciado após o término de audio2, utilizando o conector meets-start.xml, que possui essa semântica. Os binds desse elo mapeiam os dois componentes do tipo áudio com os papéis on_x_presentation_end e start_y desse conector. Como pode ser observado, o elo link1 do documento NCL representa o elo SMIL definido por meio de evento no documento da Figura 2:2, enquanto o elo link2 representa o comportamento seqüencial obtido pelo uso da composição seq em SMIL. Ao contrário de SMIL, ambos os relacionamentos são definidos da mesma forma em NCL.
Para melhor ilustrar o uso de conectores, a Figura 2:4 apresenta um conector R representando uma relação com três papéis distintos, que significam três tipos de participantes da relação. A Figura 2:4 também mostra dois elos, l1 e l2, reusando R. Enquanto o conector define o tipo de relação, o conjunto de binds de um elo define os participantes. O elo l1 especifica três binds, interligando os nós A, B e C aos papéis de R. O mesmo ocorre com l2, só que interligando um conjunto diferente de nós (B, C e D). Os elos l1 e l2 definem relacionamentos diferentes, já que interligam conjuntos distintos de nós, mas representam o mesmo tipo de relação, pois usam o mesmo conector.
xconnector papel xconnector R
A C
D
nó âncora/porta/atributo B
elo l1 R
bind elo l2 R
xconnector papel xconnector R xconnector R
A C
D
nó âncora/porta/atributo B
elo l1 R elo l1 R R
bind elo l2 R
bind bind elo l2 R elo l2 R R
Figura 2:4 - Exemplo de elos NCL e de reuso de conectores.
Um template de composição, como mencionado, pode ser utilizado para embutir semântica, por exemplo temporal, em um nó de composição. Templates de composição são definidos através da linguagem XTemplate (Muchaluat-Saade, 2003) de NCL. A definição de um template de composição é feita através de um vocabulário, que especifica tipos de componentes, tipos de relações (modeladas por conectores) e pontos de interface. A definição também pode incluir restrições sobre elementos do vocabulário e conter instâncias de componentes e relacionamentos entre componentes (modelados por elos).
Um exemplo do uso de um template de composição pode ser visto na Figura 2:5, onde é definido que um áudio deve ser sincronizado com um logo (sincronismo de início e término de apresentação), e que cada trecho do áudio deve ser sincronizado, de forma similar, com a respectiva legenda
14. Quando esse template é herdado por uma composição com um nó de áudio e três legendas (como na Figura 2:5), a composição passa a conter elos de sincronismo entre as legendas e o áudio, e entre o áudio e o logo. É importante ressaltar que o logo, definido como instância de componente no template, também passou a ser contido pela composição, após o processamento do template
15.
14
Note que o conector utilizado na especificação dos elos de sincronismo para término de apresentação (conector P, ou finishes, na Figura 2:5) é o mesmo utilizado no exemplo da Figura 2:3.
15
O Processador de Templates é responsável por atribuir a semântica de um template à
composição que o referencia.
Figura 2:5 - Exemplo do uso de templates de composição.
Maiores detalhes sobre as especificações de templates de composição serão abordados no próximo capítulo, ao se apresentar a proposta de extensão da linguagem XTemplate.
lyrics-part1 (text)
samba (audio)
Conector L => starts Conector P=>finishes
...
subt. 1 subt. 2 subt. 3 subt. n audio
Template de Composição “audio with-subtitles”-
L1
L2 P2
P1
track1 track2 trackN
logo
Pn+1 track3
L3 P3 L4 P4 Ln+1
Composição “samba -document”
lyrics-part2 (text)
lyrics-part3 (text)
+ =
lyrics-part1 (text)
samba (audio)
lyrics-part2 (text)
lyrics-part3 (text)
Composição “samba-document”
logo (img) P1
L1
L2
P2
L3
P3
P4
L4 lyrics-part1
(text)
samba (audio)
L => starts P=>finishes
processada
lyrics-part1 (text)
samba (audio)
Conector L => starts Conector P=>finishes
...
subt. 1 subt. 2 subt. 3 subt. n audio
Template de Composição “audio with-subtitles”-
L1
L2 P2
P1
track1 track2 trackN
logo
Pn+1 track3
L3 P3 L4 P4 Ln+1
Composição “samba -document”
lyrics-part2 (text)
lyrics-part3 (text)
+ =
lyrics-part1 (text)
samba (audio)
lyrics-part2 (text)
lyrics-part3 (text)
Composição “samba-document”
logo (img) P1
L1
L2
P2
L3
P3
P4
L4 lyrics-part1
(text)
samba (audio)
L => starts P=>finishes
processada
3
Nested Context Language 2.1
NCL - Nested Context Language - é uma linguagem declarativa para autoria de documentos hipermídia baseada no modelo conceitual NCM - Nested Context Model (Casanova et al., 1991; Soares et al., 1995; Soares et al., 2000; Soares et al., 2003). A primeira versão de NCL (Antonacci, 2000; Antonacci et al., 2000a;
Antonacci et al., 2000b) foi especificada por meio de uma única DTD. Utilizando as tecnologias XML descritas no Capítulo 2, NCL 2.0 (Silva et al., 2004a;
Muchaluat-Saade et al., 2003; Muchaluat-Saade, 2003) foi definida de forma modular, usufruindo de todas as vantagens citadas para essa forma de definição.
Além da abordagem modular, NCL 2.0 apresenta como principais diferenças, em relação à versão anterior da linguagem, os conceitos de templates de composição e de conectores hipermídia. Este capítulo descreve a linguagem NCL 2.1 (cuja especificação encontra-se no Apêndice B), destacando suas diferenças em relação à NCL 2.0.
3.1.
Funções de Custo
CostFunctions é o primeiro módulo introduzido por NCL 2.1, possibilitando
a definição de funções de custo. Funções de custo permitem especificar a duração
de objetos de maneira flexível, ou seja, ao invés de possuir um único valor, essa
duração pode ser definida como uma faixa de valores aceitáveis. A partir dos
custos associados a cada valor, é oferecida uma métrica que auxilia o formatador
hipermídia na escolha da melhor configuração temporal para uma determinada
apresentação (Bachelet et al., 2000).
O módulo CostFunctions define os seguintes elementos: costFunctionBase, costFunction e costFunctionParam. O conteúdo e atributos desses elementos podem ser consultados na Tabela 1
16.
Elemento Atributos Conteúdo
costFunctionBase id, ref costFunction+
costFunction id, type, ref, mathMLRef costFunctionParam*
costFunctionParam name, value Tabela 1 - Elementos do módulo CostFunctions.
Funções de custo são agrupadas em bases de funções de custo (elemento costFunctionBase), declaradas, como será visto, no cabeçalho (elemento head) de um documento NCL. Bases de funções de custo podem declarar um atributo ref para referenciar uma base de um outro documento NCL. A base CFB2 (linha 14 da Figura 3:1), por exemplo, referencia a base de funções de custo costFuncBaseA definida em "doc2.ncl".
01 <costFunctionBase id="CFB1">
02 <costFunction id="costFunction22" type="linear">
03 <costFunctionParam name="deltaShrink" value="20%"/>
04 <costFunctionParam name="deltaStretch" value="20%"/>
05 <costFunctionParam name="maxShrinkCost" value="2000"/>
06 <costFunctionParam name="maxStretchCost" value="2000"/>
07 </costFunction>
08 <costFunction id="costFunction24" ref="costFunction22">
09 <costFunctionParam name="maxShrinkCost" value="4000"/>
10 </costFunction>
11 <costFunction id="costFunction02" ref="doc1.ncl#costFunctionA" />
12 <costFunction id="costFunction03" mathMLRef="mathFunction1.xml" />
13 </costFunctionBase>
14 <costFunctionBase id="CFB2" ref="doc2.ncl#costFuncBaseA/>
Figura 3:1 - Exemplo de funções de custo em NCL 2.1.
Funções de custo (elemento costFunction) possuem um identificador (atributo id), um tipo
17(atributo type) e, possivelmente, uma referência ou para outra função de custo (atributo ref) ou para um arquivo em MathML (W3C, 2003) (atributo mathMLRef)
18. A função de custo costFunction02 (linha 11) referencia a
16
Os símbolos das tabelas de elementos apresentadas neste texto possuem os seguintes significados: (?) opcional, (|) ou, (*) zero ou mais ocorrências, (+) uma ou mais ocorrências.
17
O tipo da função de custo não é restringido por NCL, sendo necessário que os compiladores de documentos dessa linguagem (ver capítulo 5) interpretem o valor desse atributo.
18
A interpretação de funções de custo definidas por documentos MathML é
responsabilidade dos compiladores NCL.
função costFunctionA de "doc1.ncl", enquanto costFunction03 (linha 12) referencia a função declarada pelo arquivo MathML "mathFunction1.xml".
Parâmetros (elemento costFunctionParam) também podem ser definidos para funções de custo, especificados através de um nome (atributo name) e um valor (atributo value). Na Figura 3:1, a função de custo costFunction22 (linhas 2- 7), do tipo linear, define quatro parâmetros (linhas 3-6). Esses parâmetros determinam que os objetos que referenciam essa função podem ter suas durações reduzidas (deltaShrink) ou aumentadas (deltaStretch) em até 20%, sendo o custo máximo respectivo para cada ajuste (maxShrinkCost e maxStretchCost) de 2000 (o custo de ajuste aumenta linearmente até atingir seu valor máximo, já que a função é do tipo linear). Combinando o uso de parâmetros com o atributo ref, é possível redefinir parcialmente uma função de custo. Por exemplo, a função costFunction24 (linhas 8-10) referencia a função costFunction22 (herdando seus atributos e seu tipo) e redefine o custo máximo de redução (maxShrinkCost) para 4000. Ou seja, objetos referenciando costFunction24 apresentam um maior grau de dificuldade para terem suas durações reduzidas quando comparados a objetos que referenciem costFunction22
19.
3.2.
Regras de Apresentação
NCL permite a especificação de alternativas de conteúdo, assim como alternativas de exibição, para documentos. Conteúdos (nós) alternativos são agrupados em elementos switch, devendo uma entre as alternativas ser escolhida para exibição, dependendo do contexto de apresentação (ver Capítulo 1). De forma análoga, alternativas de exibição são oferecidas por meio de switches de descritores (elemento descriptorSwitch), que contêm conjuntos de descritores alternativos. Descritores (elemento descriptor) especificam as informações de apresentação de nós de forma independente da definição do nó (ou seja, pode-se definir diferentes especificações de apresentação para um mesmo nó, associando- se diferentes descritores a ele).
19
A associação de objetos a funções de custo é realizada pelo uso do atributo costFunction
(também definido pelo módulo de funções de custo), como será visto na Seção 3.3.
Em NCL 2.0, a escolha entre alternativas (de nós ou de descritores) é realizada através de atributos de teste, da mesma maneira que em SMIL
20. Assim, atributos de teste devem ser declarados juntamente com elementos NCL, e, caso todos os atributos sejam avaliados como verdadeiros no contexto de apresentação, esse elemento está apto a ser escolhido entre as alternativas.
Na Figura 3:2 é apresentado um nó switch em NCL 2.0. Entre as alternativas, existem 3 nós de áudio (aEn1, aPt1 e aFr1), que somente podem ser escolhidos para a apresentação se a largura de banda disponível for maior ou igual a 128Kbps e a língua definida for inglês, português ou francês, respectivamente.
Note que o autor, ao desejar que o mesmo áudio seja apresentado caso o leitor do documento possua conhecimento de qualquer uma dessas três línguas, teve de definir três nós referenciando - pelo atributo src - o mesmo arquivo de áudio. Em seguida, estão declarados um nó de vídeo (vid1) e um nó de imagem (img1), que são elegíveis para exibição se a banda disponível for maior ou igual a 128Kbps e 64Kbps, respectivamente. Finalmente, há um nó de texto que, por não possuir atributos de teste, pode ser exibido sem restrições. Quando o switch for avaliado, o primeiro nó apto para exibição (na seqüência do documento) será o escolhido entre as alternativas.
01 <switch id="intro">
02 <audio id="aEn1" src="a1.wav" systemLanguage="en" systemBitrate="128000" />
03 <audio id="aPt1" src="a1.wav" systemLanguage="pt" systemBitrate="128000" />
04 <audio id="aFr1" src="a1.wav" systemLanguage="fr" systemBitrate="128000" />
05 <video id="vid1" src="v1.mpg" systemBitrate="128000" />
06 <img id="img1" src="i1.jpg" systemBitrate="64000"/>
07 <text id="txt1" src="t1.txt" />
08 </switch>
Figura 3:2 - Exemplo de um nó switch em NCL 2.0
NCL 2.1 introduz o módulo TestRules para definição de regras de apresentação a serem usadas para a escolha entre alternativas de conteúdo e de descritores. Os elementos definidos por esse módulo estão apresentados na Tabela
20
