Linguagem NCL versão 2.0 para Autoria Declarativa de Documentos Hipermídia *

Linguagem NCL versão 2.0 para Autoria Declarativa de Documentos Hipermídia * Débora C. Muchaluat Saade 1, Heron V. Silva 2, Luiz Fernando G. Soares 2 1 Departamento de Engenharia de Telecomunicações UFF R. Passo da Pátria, 156 São Domingos 24210-240 Niterói RJ Brasil 2 Departamento de Informática PUC-Rio R. Marquês de São Vicente, 225 Gávea 22453-900 Rio de Janeiro RJ Brasil deborams@telecom.uff.br, heron@inf.puc-rio.br, lfgs@inf.puc-rio.br Abstract. This paper presents the Nested Context Language (NCL) version 2.0, a declarative authoring language for hypermedia documents. NCL 2.0 is a modular language, which provides several facilities for authoring a complete hypermedia document with synchronization relationships among its components. Among its main facilities, we can highlight treating hypermedia relations as first-class entities, through the definition of hypermedia connectors, and the possibility of specifying any semantics for a hypermedia composition using the concept of composite templates. NCL 2.0 modules can be added to standard web languages, such as XLink and SMIL. Resumo. Este artigo apresenta a versão 2.0 da linguagem NCL Nested Context Language para autoria declarativa de documentos hipermídia. NCL 2.0 é uma linguagem modular, que fornece diversas facilidades para a autoria de um documento hipermídia, com relacionamentos de sincronização entre seus componentes. Dentre suas facilidades principais, pode-se destacar o tratamento de relações hipermídia como entidades de primeira classe, através da definição de conectores hipermídia, e a possibilidade de especificar qualquer semântica para uma composição hipermídia usando o conceito de template de composição. Os módulos de NCL 2.0 podem ser adicionados a linguagens web padronizadas, tal como XLink e SMIL. 1. Introdução NCL Nested Context Language é uma linguagem declarativa para autoria de documentos hipermídia baseados no modelo conceitual NCM Nested Context Model [SoRM00]. A primeira versão de NCL [AMRS00] foi especificada através de uma única DTD XML. Este artigo apresenta a nova versão de NCL, batizada de NCL 2.0, que foi especificada de forma modular, permitindo a combinação de seus módulos em perfis de linguagem. Cada perfil pode agrupar um subconjunto de módulos, possibilitando a criação de linguagens de acordo com a necessidade dos usuários. * Este trabalho foi realizado com apoio do Fundo Setorial para o Desenvolvimento Tecnológico das Telecomunicações (FUNTTEL), através do contrato 0594/02; e do CNPq

Por que mais uma linguagem? A abordagem modular presente em NCL permite não só a criação de linguagens específicas de acordo com a necessidade dos usuários, o que por si só já responderia a questão, como também, e principalmente, permite que módulos de NCL 2.0 possam ser combinados com módulos de outras linguagens. Essa última facilidade não só evitou que NCL duplicasse esforços, permitindo a incorporação de características de linguagens modulares à NCL 2.0 (como se verá, particularmente SMIL 2.0), mas, principalmente, permite a incorporação de novas características presentes em NCL 2.0 a várias linguagens, como as realizadas para as linguagens XLINK [MuRS02], SMIL 2.0 e XHTML [Much03], como será discutido na Seção 3.13. Comparando NCL 2.0 com a sua versão anterior, além da estrutura modular, NCL 2.0 introduz novas facilidades na linguagem de autoria. Dentre as facilidades, podese ressaltar: o tratamento de relações hipermídia como entidades de primeira classe, através da definição de conectores hipermídia e de bases de conectores [MuCS01], que permite a especificação de relações de sincronização e de referência de forma independente dos relacionamentos contidos nos documentos; o uso de conectores hipermídia para a autoria de elos; a definição de bases de elos e o reuso de elos e bases de elos em diferentes documentos; a definição de portas e mapeamentos para nós de composição, satisfazendo a propriedade de composicionalidade dos documentos; a definição de templates de composição hipermídia [MuSo02], permitindo a especificação de semânticas para composições hipermídia, o reuso da definição de estruturas e a especificação de restrições sobre documentos; a definição de bases de templates de composição e o uso de templates de composição para a autoria de nós de composição; o refinamento da especificação de documentos com alternativas de conteúdo, através do elemento switch, que agrupa um conjunto de nós alternativos; o refinamento da especificação de documentos com alternativas de apresentação, através do elemento descriptorswitch, que agrupa um conjunto de descritores alternativos, como será detalhado mais adiante; o uso de um novo modelo de layout espacial [Mour01], que possibilita especificar informações para posicionamento de objetos em um dispositivo de saída. Este artigo está estruturado como se segue. A Seção 2 realiza um breve resumo sobre modelagem de documentos usando a nova versão do NCM, modelo conceitual no qual NCL 2.0 se baseia. A Seção 3 apresenta os módulos da linguagem NCL 2.0 e comenta alguns perfis de linguagem. A Seção 4 apresenta um exemplo de documento NCL 2.0. A Seção 5 apresenta a comparação com trabalhos relacionados, destacando as comparações com a linguagem SMIL 2.0. Finalmente, a Seção 6 apresenta as conclusões e os trabalhos futuros.

2. Documentos Hipermídia no Modelo NCM Um documento hipermídia no modelo NCM é representado por um nó de composição, podendo conter um conjunto de nós, que podem ser objetos de mídia ou outros nós de composição, recursivamente, e ainda elos relacionando esses nós. Uma restrição do modelo impede que um nó contenha, recursivamente, ele próprio. Nós de composição no modelo NCM não têm nenhuma semântica embutida, diferente das composições SMIL 2.0 [SMIL01], por exemplo, que têm semântica temporal. A semântica de um nó de composição é deixada para linguagens de autoria baseadas no modelo. No caso da linguagem NCL, uma semântica específica para um nó de composição pode ser dada por um template de composição [MuSo02]. Para permitir a criação de relacionamentos entre partes internas do conteúdo de um nó, o modelo permite a definição de pontos de interface, que definem âncoras ou atributos, para qualquer tipo de nó, ou ainda portas, no caso de um nó de composição. Uma porta de um nó de composição é sempre mapeada em um ponto de interface de um de seus nós internos. Relacionamentos entre os componentes de um documento NCM são feitos através de elos. Elos NCM são definidos fazendo referência a um conector hipermídia, que pode representar qualquer tipo de relação [MuCS01], entre elas: relações de referência, de sincronização, de derivação, entre tarefas de um trabalho cooperativo etc. Além da referência a um conector, um elo define um conjunto de binds associando papéis do conector a pontos de interface de nós do documento. Cada extremidade de um elo indica, assim, um ponto de interface, modelando relacionamentos multiponto entre vários nós de um documento. Como uma porta de um nó de composição é mapeada em um ponto de interface de um de seus nós componentes, a criação de elos entre nós internos a uma composição e nós que não pertencem à mesma composição é possível. A versão anterior do modelo NCM [SoRM00] especificava uma outra restrição que exigia que todas as extremidades de um elo fossem componentes da composição onde o elo foi definido. Entretanto, na nova versão [SoRM03], essa restrição é deixada para linguagens de autoria baseadas no modelo, permitindo que o NCM também possa ser usado para modelar documentos que não têm esse tipo de restrição, como, por exemplo, documentos web. Vale ressaltar, no entanto, que, se essa restrição não for obedecida, a propriedade de composicionalidade do documento, tão importante na prova formal de propriedades, é perdida. Na nova versão do NCM, elos são sempre agrupados em bases de elos, logo, o conjunto de elos de uma composição pode ser dado pela união de elos de diferentes bases. Além do reuso de nós, permitido em versões anteriores do NCM [SoRM00], a nova versão também permite o reuso de elos e de bases de elos em outras bases, tornando mais flexível a definição de elos no modelo. A especificação de apresentação de um nó no modelo NCM é feita independente da definição do nó, sendo representada por outro objeto do modelo, chamado descritor [SoRM00]. Com isso, pode-se definir diferentes especificações de apresentação para um mesmo nó, pela associação de diferentes descritores a esse nó. Um nó pode ter um descritor definido por seu tipo (áudio, vídeo, texto, imagem, composição etc.), um outro descritor definido pelo próprio nó (normalmente especificado pelo seu autor), um outro

descritor definido por cada composição a que pertence, um outro descritor definido por cada elo que o toca e ainda, um descritor definido pelo usuário final (leitor). No caso de um nó possuir todos esses descritores especificados, o descritor resultante a ser associado a esse nó, para especificar sua apresentação final, será a combinação das especificações de todos esses descritores, de acordo como seguinte cascateamento: atributos do descritor definido pelo usuário sobrescrevem atributos do descritor definido pelo elo, que, por sua vez, sobrescrevem atributos do descritor definido pela composição, que, por sua vez, sobrescrevem atributos do descritor definido pelo próprio nó, que, por último, sobrescrevem atributos do descritor da classe do nó. Além disso, visando a especificação de apresentações multimídia adaptativas, cada especificação de apresentação pode, na verdade, ao invés de especificar um único descritor, especificar um conjunto de descritores alternativos, apresentando opções de apresentação para o mesmo nó. Dentre as opções especificadas, uma delas deverá ser escolhida, dependendo de características da plataforma de exibição e do usuário final. Uma outra entidade introduzida pela nova versão do modelo NCM é um nó que agrupa um conjunto de nós alternativos, denominado nó switch, tal como em SMIL, que também pode ser usado para a especificação de documentos hipermídia adaptáveis a uma plataforma de exibição ou a um perfil de usuário específico. Além disso, um nó switch pode especificar alternativas de apresentação para cada um de seus componentes, através de conjuntos de descritores alternativos, de forma análoga ao que um nó de composição qualquer pode realizar. Um nó switch simplifica a idéia de utilizar entidades virtuais, mais gerais, como comentado em versões anteriores do modelo [SoRM00]. Um nó switch pode definir tipos especiais de pontos de interface, que permitem ser mapeados em um conjunto de pontos de interface alternativos de seus nós componentes, onde a escolha pode ser feita em tempo de execução. Esse tipo especial de ponto de interface permite a ancoragem de elos no componente que será escolhido pela execução de um nó switch. Utilizando as entidades básicas do modelo NCM, a linguagem NCL 2.0 foi desenvolvida, introduzindo ainda outros recursos para facilitar a autoria de documentos NCM, como por exemplo, o conceito de template de composição hipermídia, apresentado em detalhes em [MuSo02, Much03]. A próxima seção apresenta a estrutura modular de NCL 2.0 e comenta alguns perfis de linguagem. 3. Modularização da linguagem NCL 2.0 Seguindo a mesma abordagem de modularização da linguagem SMIL 2.0, a funcionalidade de NCL 2.0 está dividida em onze áreas funcionais, que, por sua vez, estão particionadas em módulos. Como NCL 2.0 tem algumas facilidades idênticas às de SMIL 2.0, alguns módulos de SMIL 2.0 são usados por NCL 2.0. As próximas subseções descrevem, de maneira sucinta, as principais definições feitas por cada área funcional da linguagem e seus módulos correspondentes. A definição completa, em XML Schema, dos módulos de NCL 2.0 está disponível em [Much03]. 3.1 Área Funcional Structure: Módulo Structure O módulo Structure define a estrutura básica de um documento NCL. São definidos o elemento raiz, chamado ncl, o cabeçalho e o corpo do documento, chamados

respectivamente de head e body. O corpo de um documento NCL pode ser tratado como um nó de composição, contendo outros nós e/ou bases de elos. 3.2 Área Funcional Components: Módulos BasicMedia e BasicComposite O módulo BasicMedia define os tipos básicos de objetos de mídia que um documento NCL pode conter. Esse módulo é idêntico ao módulo BasicMedia do SMIL, definindo os seguintes elementos animation, audio, img, text, textstream, video e ref. O elemento ref permite definir uma referência a um outro objeto, permitindo o reuso de objetos em diferentes documentos. Cada objeto de mídia possui dois atributos principais: o atributo src que define uma URI com o conteúdo do objeto e o atributo type, que define o tipo MIME do objeto, além do atributo id. O módulo BasicComposite é responsável pela definição de nós de composição (vide Seção 2) em documentos NCL. Assim sendo, o elemento composite, que representa o nó de composição, pode conter elementos definidos pelo módulo BasicMedia, outros elementos composite e ainda elementos linkbase, que agrupam a definição dos elos da composição. O conteúdo de elementos linkbase será definido na Seção 3.5, que aborda o módulo Linking. 3.3 Área Funcional Interfaces: Módulos MediaInterface, CompositeInterface, AttributeInterface e SwitchInterface O módulo MediaInterface permite a definição de âncoras para objetos de mídia. Esse módulo define o elemento area, que estende a sintaxe e semântica do elemento homônimo definido por SMIL e XHTML. Além de permitir a definição de âncoras representando porções espaciais, através do atributo coords (como em XHTML [XHTM01]), e a definição de âncoras representando porções temporais, através dos atributos begin, end e dur, como em SMIL, o elemento area permite a definição de âncoras textuais, através dos atributos text, que define a cadeia de caracteres, e position, que define a posição inicial da cadeia no texto. Além das âncoras textuais, o módulo MediaInterface permite a definição de âncoras baseadas em número de amostras, para mídia áudio, ou número de quadros, para mídia vídeo, através dos atributos first e last, que devem indicar o número da amostra/quadro inicial e final. Um perfil de linguagem que usa esse módulo deve acrescentar o elemento area como elemento-filho dos elementos que definem objetos de mídia, especificados pelo módulo BasicMedia. O módulo CompositeInterface permite a definição de âncoras e portas para nós de composição. Esse módulo define um elemento chamado areacomposite, usado para a criação de âncoras, através de seu atributo componentlist, que contém uma lista de identificadores de nós componentes do nó de composição. Além do elemento areacomposite, o módulo CompositeInterface também especifica o elemento port, que define uma porta com seu respectivo mapeamento para um ponto de interface (atributo port) de um de seus nós componentes (atributo component). Um perfil de linguagem que usa esse módulo deve acrescentar os elementos areacomposite e port como elementosfilho do elemento composite, especificado pelo módulo BasicComposite. O módulo AttributeInterface permite a definição de atributos de nós como pontos de interface. Esse módulo define um elemento chamado attribute, cujo atributo name indica o nome do atributo em questão. Um perfil de linguagem que usa esse

módulo deve acrescentar o elemento attribute como elemento-filho dos elementos que definem objetos de mídia, especificados pelo módulo BasicMedia, ou do elemento composite, especificado pelo módulo BasicComposite. O módulo SwitchInterface permite a definição de pontos de interface especiais para elementos switch, que serão comentados na Seção 3.10. Esses pontos de interface podem ser mapeados em um conjunto de alternativas de pontos de interface de seus nós internos, permitindo a ancoragem de elos no componente escolhido durante a exibição de um nó switch (veja Seção 2). Esse módulo introduz o elemento portswitch, que contém um conjunto de elementos port, de acordo com a definição feita pelo módulo CompositeInterface, mencionada anteriormente. Um perfil de linguagem que usa esse módulo deve acrescentar os elementos portswitch e port como elementos-filho de um elemento switch, especificado pelo módulo ContentControl, descrito na Seção 3.10. A definição de elementos port e portswitch introduzidos pelos módulos CompositeInterface e SwitchInterface são novas facilidades que NCL 2.0 oferece. 3.4 Área Funcional Connectors: Módulos XConnector e CompositeConnector A área funcional Connectors traz novas facilidades, não encontradas em nenhuma outra linguagem hipermídia. O módulo XConnector permite a definição de conectores hipermídia, através do elemento xconnector, e de bases de conectores, através do elemento connectorbase. Um conector hipermídia representa uma relação que será usada para criar elos entre nós de um documento. Ele especifica a semântica da relação, mas não especifica quais nós participarão do relacionamento. Os nós serão especificados pelos elos hipermídia que usarão o conector, como será comentado na Seção 3.5. Um conector é definido por um conjunto de pontos de interface, chamados roles (papéis), e outro elemento filho chamado glue. Cada papel de um conector especifica a função de um participante da interação, e o glue do conector descreve como os participantes interagem, completando a definição da semântica da relação. XConnector permite a definição de conectores representando relações de sincronização e de referência. O módulo XConnector é apresentado em detalhes em [MuRS02]. O módulo CompositeConnector permite a definição de conectores compostos, tal como discutido em [MuCS01]. Um conector composto é definido pelo elemento compositeconnector, que contém elementos role e um elemento glue, tal como um conector simples. Entretanto, cada elemento role de um conector composto é mapeado em um ponto de interface de uma ocorrência de um conector interno (mapeamento chamado de elo parcialmente definido, de acordo com [MuCS01]). Além disso, o glue de um conector composto é definido como um nó de composição, que contém o mesmo conteúdo que um elemento composite e ainda o conjunto de elos parcialmente definidos, chamado de partiallinkbase. 3.5 Área Funcional Linking: Módulo Linking O módulo Linking é responsável pela definição de elementos para a criação de elos usando conectores. Um elo é definido pelo elemento link, que possui, além do atributo id, um atributo chamado xconnector, que faz referência à URI de um conector

hipermídia. Se o conector referenciado definir parâmetros, o elo deve associar valores para esses parâmetros [Much03]. O elemento link contém ainda elementos-filho chamados bind, que permitem associar os nós relacionados pelo elo a papéis do conector usado. Para realizar tal associação, um elemento bind possui três atributos básicos. O primeiro é chamado role, sendo usado para fazer referência a um papel do conector usado. O segundo é chamado component, que deve fazer referência ao identificador único de um nó, e o terceiro é chamado port 1, usado para fazer referência a um ponto de interface do nó associado. Além do elemento link, o módulo Linking define um outro elemento chamado linkbase, que permite a definição de bases de elos. Além disso, esse módulo ainda especifica o elemento lref, que pode ser usado para fazer referência a um elo ou uma base de elos já definidos, permitindo o reuso de elos e bases de elos em diferentes documentos. O elemento lref, análogo ao elemento ref, definido pelo módulo BasicMedia, tem um atributo src que identifica o elemento sendo reusado. Um elemento linkbase pode conter elementos link ou lref. A definição de bases de elos e o reuso de elos introduzidos pelo módulo Linking são duas novas facilidades que NCL 2.0 oferece. 3.6 Área Funcional Composite Templates: Módulos XTemplate e XTemplateUse A área funcional CompositeTemplates também traz novas facilidades não encontradas em nenhuma outra linguagem hipermídia. O módulo XTemplate permite a definição de templates de composição hipermídia, através do elemento xtemplate e de bases de templates, através do elemento templatebase. Um template de composição pode ser utilizado para embutir semântica, por exemplo temporal, em um nó de composição. A definição de um template de composição é feita através de um vocabulário, que define tipos de componentes, tipos de relações (modeladas por conectores) e pontos de interface; e de um conjunto de restrições sobre elementos do vocabulário e inclusão de instâncias de componentes e relacionamentos entre eles (modelados por elos). O módulo XTemplate é apresentado em detalhes em [MuSo02]. O uso do módulo XTemplate, por um determinado perfil de linguagem, exige que um módulo que define conectores, tal como XConnector, seja também utilizado, pois a semântica de elos definidos em um template de composição é dada pela definição de conectores hipermídia. O módulo XTemplateUse permite a utilização de templates por nós de composição em documentos NCL. Para isso, esse módulo define o atributo xtemplate, que faz referência à URI de um template de composição e define o atributo label, que especifica um rótulo. Um perfil de linguagem que use esse módulo deve acrescentar o atributo xtemplate à definição do elemento composite e o atributo label à definição de objetos de mídia, de elementos composite e de pontos de interface de nós. 1 Note que o atributo port, em um elemento bind, pode fazer referência a qualquer ponto de interface de um nó, ou seja, uma âncora, um atributo ou uma porta, no caso de um nó de composição.

3.7 Área Funcional Timing: Módulo BasicTiming O módulo BasicTiming permite a definição de especificações temporais para componentes de um documento. Basicamente, esse módulo define atributos para especificação da duração ideal (dur), duração mínima (min) e duração máxima (max) de um objeto qualquer, que serão utilizados por descritores, que, por sua vez, agrupam toda a especificação de apresentação de componentes do documento, como será definido na Seção 3.9. Essa área funcional pode incluir um outro módulo que permite a especificação de funções de custo para informar a melhor forma de realizar ajustes nas durações do objetos, caso seja necessário realizar esse tipo de adaptação durante a apresentação [Rodr03]. Um função de custo poderia ser associada à especificação temporal de cada objeto. Entretanto, a definição desse outro módulo foi deixada para trabalho futuro. 3.8 Área Funcional Layout: Módulo BasicLayout O módulo BasicLayout especifica elementos e atributos que definem como os objetos serão apresentados em regiões na tela de um dispositivo de exibição. O modelo de layout usado por NCL 2.0 é apresentado em detalhes em [Mour01]. Em resumo, um elemento layout, que deve ser declarado no cabeçalho de um documento, define um conjunto de janelas (toplayout), que contêm um conjunto de regiões (region), que, por sua vez, podem conter outro conjunto de regiões aninhadas. Tanto janelas quanto regiões podem definir os seguintes atributos: id, title, left, top, height, width, backgroundcolor, zindex, scroll, open, close. Além disso, regiões também podem definir o atributo fit, indicando como um objeto deve ser apresentado na região indicada. Todos esses atributos têm o mesmo significado e os mesmos valores possíveis dos atributos homônimos definidos nos módulos de layout da linguagem SMIL 2.0, exceto o atributo scroll, que permite ao usuário especificar como deseja configurar o scroll de uma região [Rodr03]. Apesar de NCL definir seu modelo de layout, nada impede que um documento NCL possa utilizar outros modelos de layout, desde que eles definam regiões onde objetos devam ser exibidos, como por exemplo os modelos de layout definidos por SMIL 2.0. Sendo assim, o elemento layout pode especificar um atributo src, que indica a URI do documento contendo a especificação de layout, e não precisa conter, nesse caso, conteúdo algum. 3.9 Área Funcional Presentation Specification: Módulo BasicDescriptor e CompositeDescriptor O objetivo dessa área funcional é especificar as informações temporais e espaciais necessárias para apresentar cada componente de um documento, modeladas no NCM, por objetos chamados descritores. O módulo BasicDescriptor permite a definição do elemento descriptor, que contém um conjunto de atributos opcionais, agrupando todas as definições temporais e espaciais, que devem ser utilizados de acordo com o tipo do objeto a ser apresentado. A definição de elementos descriptor deve ser feita no cabeçalho de um documento (head), dentro do elemento descriptorbase, que especifica o conjunto de descritores do documento. Um elemento descriptor possui os atributos temporais dur, min e max definidos pelo módulo BasicTiming (veja Seção 3.7); um atributo chamado player, que

identifica a ferramenta de exibição a ser utilizada; um atributo chamado region, que faz referência a uma região definida por elementos do módulo BasicLayout (veja Seção 3.8); e ainda um atributo chamado enabletimebar, usado para habilitar uma barra de rolagem de tempo, caso se aplique. Além desses atributos, um elemento descriptor também pode definir o atributo style, que faz referência a uma folha de estilo, com informações para apresentação de textos, por exemplo; e ainda atributos específicos para objetos com áudio, definindo soundlevel, balancelevel, treblelevel e basslevel. O módulo BasicDescriptor, além do elemento descriptor, define um atributo homônimo, que faz referência a um elemento do conjunto de descritores do documento. Um perfil de linguagem, que use o módulo BasicDescriptor, pode determinar como é feita a associação do atributo descriptor a um componente do documento. No caso do perfil NCL 2.0 Language Profile, seguindo o modelo NCM, o atributo descriptor é associado a um objeto de mídia qualquer, um nó de composição, ou ainda a uma extremidade de um elo (veja Seção 2). O módulo CompositeDescriptor define o elemento componentpresentation, que associa um nó componente de uma composição, identificado pelo atributo component, a um elemento do conjunto de descritores do documento, identificado pelo atributo descriptor. Qualquer elemento composite passa, então, a poder conter elementos componentpresentation. Vale ressaltar que o conjunto de descritores de um documento pode conter elementos descriptor ou ainda elementos descriptorswitch, que permitem especificar descritores alternativos, como será apresentado na próxima seção. 3.10 Área Funcional Presentation Control: Módulos TestAttributes, ContentControl e DescriptorControl Os objetivos da área funcional Presentation Control são similares e estende aqueles da área funcional Content Control da linguagem SMIL 2.0. Resumidamente, os objetivos são especificar alternativas de conteúdo e, ainda, de exibição para um documento. O módulo TestAttributes permite a definição de atributos de teste usados para especificar alternativas para a apresentação de um documento. Os atributos de teste são exatamente os mesmos pré-definidos pelo módulo BasicContentControl de SMIL 2.0. A especificação dos atributos de teste foi feita em um módulo separado de NCL, pois será útil tanto para definir componentes alternativos, como para definir descritores alternativos em documentos NCL, como apresentado a seguir. O módulo ContentControl especifica o elemento switch, tal como em SMIL, permitindo a definição de nós componentes alternativos do documento, a serem escolhidos em tempo de execução. Entretanto, o elemento switch de NCL não tem conteúdo idêntico ao elemento homônimo de SMIL (definido pelo seu módulo BasicContentControl), pois pode conter, além de objetos de mídia, elementos composite, definidos pelo módulo BasicComposite de NCL 2.0. O módulo DescriptorControl especifica o elemento descriptorswitch, que contém um conjunto de descritores alternativos a serem associados a um objeto. De forma análoga ao elemento switch, a escolha do descritor a ser usado é feita em tempo de execução, usando os mesmo atributos de teste, definidos pelo módulo TestAttributes.

3.11 Área Funcional Metainformation: Módulo Metainformation A área funcional Metainformation é idêntica à área funcional de mesmo nome da linguagem SMIL 2.0 permitindo a definição de metadados sobre um documento ou sobre elementos de um documento. Toda informação sobre metadados de um documento deve ser incluída em seu cabeçalho (elemento head). 3.12 Perfis NCL 2.0 O perfil de linguagem chamado NCL 2.0 Language Profile, é o perfil completo da linguagem NCL 2.0, ou seja, que inclui todos os seus módulos e oferece todas as facilidades para a autoria declarativa de documentos NCL. A Tabela 1 indica os elementos e atributos, considerando seus modelos de conteúdo especificados no perfil completo de NCL 2.0, separados por área funcional. Na especificação do conteúdo, os símbolos indicam o seguinte: (?) opcional, ( ) ou, (*) zero ou mais ocorrências, (+) uma ou mais ocorrências. Além do perfil NCL 2.0 Language Profile, outros perfis podem ser construídos, como, por exemplo: Simple NCL Language Profile permite a criação de documentos NCL sem contemplar conectores compostos, controle de conteúdo (elemento switch), descritores alternativos, atributos como pontos de interface e definição de metadados. Esse perfil inclui os módulos Structure, BasicMedia, MediaInterface, BasicComposite, CompositeInterface, XConnector, Linking, BasicDescriptor, XTemplate e XTemplateUse. Basic Media Profile permite a criação de documentos hipermídia sem nós de composição e sem conectores compostos. Esse perfil precisa incluir os módulos Structure, BasicMedia, MediaInterface, XConnector, Linking e BasicDescriptor. Basic NCM Profile permite a criação de documentos NCM sem templates de composição hipermídia e sem conectores compostos. Esse perfil precisa incluir os módulos Structure, BasicMedia, MediaInterface, AttributeInterface, BasicComposite, CompositeInterface, XConnector, Linking, BasicDescriptor, CompositeDescriptor, TestAttributes, ContentControl, SwitchInterface e DescriptorControl. Basic Linking Profile permite a criação de elos e bases de elos sem conectores compostos. Esse perfil precisa incluir os módulos Structure, XConnector e Linking. XConnector Profile permite a criação de conectores hipermídia sem composição. Esse perfil precisa incluir apenas o módulo XConnector, que é independente dos demais módulos de NCL 2.0. XTemplate Profile permite a criação de templates de composição hipermídia e conectores sem composição. Precisa incluir os módulos XConnector e XTemplate.

Área Funcional Structure Components Interfaces Tabela 1. Modelo de Conteúdo do Perfil Completo de NCL 2.0 2 Elementos Atributos Conteúdo ncl id (head?, body) head (Metainformation*, layout?, descriptorbase?) body (BasicMedia composite switch linkbase)* animation, audio, img, id, src, type, descriptor, area*, attribute* text, textstream, vídeo, label, TestAttributes ref composite Area id, descriptor, xtemplate, label, TestAttributes id, coords, begin, end, dur, text, position, first, last, label (areacomposite*, port*, attribute*, componentpresentation*, (BasicMedia composite linkbase switch)*) Vazio areacomposite id, componentlist, label Vazio port id, component, port, Vazio label attribute id, name Vazio portswitch id, label port+ Linking bind role, component, port Vazio param name, value Vazio link id, xconnector (param*, bind+) lref id, src Vazio linkbase id (link lref)+ Connectors xconnector id (param*, role+, glue) param name, type Vazio connectorbase id xconnector+ compositeconnector id (role+, glue) Composite xtemplate id (vocabulary, constraints?) Templates templatebase id xtemplate+ Layout layout src, type toplayout* toplayout id, title, left, top, height, region* width, backgroundcolor, zindex, scroll, open, close, movable, resizable, visible region id, title, left, top, height, region* width, backgroundcolor, zindex, scroll, open, close, fit, visible Presentation descriptor id, player, dur, min, Vazio Specification max, region, enabletimebar, style, soundlevel, balancelevel, treblelevel, basslevel, TestAttributes descriptorbase (descriptor descriptorswitch)* Presentation Control componentpresentation component, descriptor Vazio switch id, TestAttributes (portswitch*, componentpresentation*, (BasicMedia composite switch)+) descriptorswitch id descriptor+ 2 A definição completa dos elementos e atributos especificados nos módulos XConnector e XTemplate foram omitidas propositalmente, e podem ser encontradas nas referências [MuRS02, MuSo02].

3.13 Incorporando Facilidades de NCL 2.0 em Outras Linguagens Um dos objetivos do projeto de NCL 2.0 foi oferecer facilidades que pudessem ser incorporadas a outras linguagens de autoria, visando principalmente a autoria de documentos web. As referências [MuRS02] e [MuSo02] discutiram, respectivamente, como os módulos XConnector e XTemplate podem ser utilizados para incorporar novas facilidades ao padrão XLink [XLIN01]. Considerando extensões ao padrão SMIL 2.0, um perfil de linguagem, chamado SMIL+XTemplate, poderia ser criado. Esse perfil permitiria a criação de outros tipos de contêineres temporais, além dos conhecidos par, seq e excl. Para dar suporte à definição de templates, os módulos BasicComposite, XConnector e XTemplate deveriam ser adicionados ao perfil. O módulo BasicComposite introduz o elemento composite que pode adquirir a semântica definida por um template qualquer. O módulo XConnector é necessário para permitir a definição de conectores, que são usados para a criação de elos em um template. Além de adicionar esses três módulos de NCL 2.0, dois novos módulos teriam que ser criados. O primeiro módulo novo deveria permitir a definição de elos SMIL através do uso de conectores, similar ao que foi feito no módulo Linking de NCL 2.0. O outro módulo novo forneceria o uso de templates de composição. Esse último módulo adicionaria o atributo xtemplate a elementos composite e o atributo label a objetos de mídia, âncoras e composições SMIL, com objetivos similares aos do módulo XTemplateUse de NCL 2.0. 4. Exemplo de Documento NCL 2.0 Para ilustrar a autoria de documentos usando a linguagem NCL 2.0, considere um documento contendo uma composição (elemento composite) identificada por sambadocument, que contém um nó de áudio e ainda uma série de nós de texto HTML, cada um deles representando partes da letra do áudio. O nó de áudio define uma série de âncoras, uma para cada trecho cantado do áudio. Para sincronizar a apresentação da letra com cada trecho correspondente do áudio, a composição samba-document utiliza um template de composição, chamado audio-with-subtitles, que embute toda a semântica temporal. A Figura 1 exibe a definição do documento NCL, realçando os atributos mais importantes para a utilização do template de composição. Para simplificar o exemplo, apenas os três primeiros trechos da letra da música foram utilizados. Note que cada nó componente do documento NCL faz referência a um descritor, definido em seu cabeçalho, que especifica suas características de exibição. <?xml version="1.0"?> <ncl id="ncl_example" xmlns="http://www.telemidia.puc-rio.br/specs/xml/ncl" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://www.telemidia.puc-rio.br/specs/xml/ncl http://www.telemidia.puc-rio.br/specs/xml/ncl.xsd"> <head> <layout> <toplayout id="window1" title="music Lyrics" width="600" height="200"> <region id="textregion1" width="65%" height="100%"/> <region id="imageregion1" width="35%" height="100%" left="65%"/> </toplayout> <toplayout id="audiowindow" title="audio Control" top="200" width="600" height="50"> <region id="audioregion1" width="100%" height="100%"/>

</toplayout> </layout> <descriptorbase> <descriptor id="audio_d1" region="audioregion1" enabletimebar="on" /> <descriptor id="text_d1" region="textregion1" /> <descriptor id="img_d1" region="imageregion1" /> </descriptorbase> </head> <body> <composite id="samba-document" xtemplate="http://engenho.telemidia.pucrio.br/users/debora/audio-with-subtitles.xml"> <audio id="samba" label="audio" src="http://www.telemidia.pucrio.br/specs/xml/examples/samba/samba.wav" descriptor="audio_d1"> <area id="part1" begin="8.4s" end ="18s" label="track"/> <area id="part2" begin="18.5s" end ="28s" label="track"/> <area id="part3" begin="29s" end ="39s" label="track"/> </audio> <text id="lyrics-part1" label="subtitle" src="http://www.telemidia.pucrio.br/specs/xml/examples/samba/lyrics01.htm" descriptor="text_d1"/> <text id="lyrics-part2" label="subtitle" src="http://www.telemidia.pucrio.br/specs/xml/examples/samba/lyrics02.htm" descriptor="text_d1"/> <text id="lyrics-part3" label="subtitle" src="http://www.telemidia.pucrio.br/specs/xml/examples/samba/lyrics03.htm" descriptor="text_d1"/> </composite> </body> </ncl> Figura 1. Exemplo de documento NCL 2.0 Um template de composição define uma semântica para um nó de composição. No exemplo, o template audio-with-subtitles define a sincronização temporal entre um nó de áudio qualquer (tipo de componente com rótulo audio) e as legendas correspondentes a parte cantada/falada do áudio (tipo de componente com rótulo subtitle). Ao utilizar um template, o nó de composição deve indicar sua URI e associar rótulos definidos pelo template aos seus componentes específicos, tal como realçado na Figura 1. A Figura 2 ilustra a representação gráfica desse template mostrando suas visões estrutural e temporal. Os elos L i e P i utilizam, respectivamente, conectores que representam as relações de sincronização starts e finishes de Allen [Alle83]. Além disso, o template especifica que uma imagem seja apresentada em paralelo com o áudio (tipo de componente com rótulo logo). A definição completa desse template em XML pode ser encontrada em [Much03]. subtitle 1 logo L 2 L 3 P L 1 P1 2 L 4 P 3 audio P n+1 P L 4 n+1... subtitle n Visão Estrutural subtitle 2 subtitle 3 logo L 1 audio P 1 track1 track2 track3 trackn L 2 P 2 L 3 P 3 L 4 P 4 L n+1... subt. 1 subt. 2 subt. 3 subt. n Visão Temporal P n+1 Figura 2. Representação gráfica do template audio-with-subtitles

Como o uso de templates de composição é uma facilidade da linguagem de autoria NCL 2.0, e não do modelo NCM, um documento NCL que usa um template de composição precisa ser processado antes de ser entregue para ser exibido. O processamento de documentos usando templates é realizado por um processador de templates, que gera um novo documento NCL a partir da definição do documento original e do template, como ilustrado na Figura 3. O documento NCL final contém as definições de componentes e relacionamentos especificadas no template, além das definições do documento original. O documento final do exemplo dado pode ser encontrado em [Much03]. Documento NCL usando um template template de composição processador de templates de composição Valida restrições e gera componentes e elos automaticamente Documento NCL ou Relatório de erros Documento final Figura 3. Processamento de documentos NCL com templates de composição Ao executar o documento final samba-document usando o formatador NCM [Rodr03], cada trecho do áudio é sincronizado com a parte da letra correspondente. As Figuras 4 e 5 exibem o documento apresentado ao usuário final, mostrando as duas primeiras partes da letra do samba sincronizadas com o áudio (note o progresso na barra de rolagem de tempo que controla a exibição do áudio). Figura 4. Primeira tela da apresentação do documento samba-document Figura 5. Segunda tela da apresentação do documento samba-document 5. Trabalhos Relacionados Sabe-se que, atualmente, a linguagem SMIL 2.0 é o padrão consagrado pelo W3C para autoria de documentos multimídia interativos. A pergunta da Seção 1, Por que então uma nova linguagem, sendo que já existe um padrão com objetivos similares? pode agora ser considerada com mais profundidade. A representação de relacionamentos através de composições com semântica embutida, que é a abordagem usada por SMIL em seus contêineres temporais, facilita bastante o trabalho do autor por evitar que ele tenha que criar vários elos entre um grupo de nós para obter uma semântica idêntica à da composição. Por outro lado, nesse tipo de abordagem, relacionamentos mais complexos entre um conjunto de componentes têm que ser descritos por uma hierarquia de composições usando os tipos básicos. Isso nem sempre é desejável, pois obriga a estrutura lógica do documento a ser igual a sua estrutura de apresentação temporal.

A especificação de relacionamentos de sincronização através de elos, que é a abordagem de NCL desde sua primeira versão [AMRS00], permite que o uso de composições possa ser dedicado à criação de relações de estruturação entre componentes de um documento. Além disso, o uso de elos para definir o sincronismo temporal permite que um autor defina qualquer tipo de relação de sincronização entre um grupo de componentes. Essa abordagem dá mais flexibilidade, já que o autor não precisa ficar limitado a alguns tipos de composição pré-definidos pela linguagem e pode estruturar seu documento de forma independente de suas relações de sincronização. Dadas vantagens e desvantagens do uso de composições e elos para representar relações, o ideal é oferecer ao autor todas as possibilidades: o uso de composições para estruturação lógica e o uso de elos para especificar sincronização; e o uso de composições com semântica, por exemplo temporal, fazendo a estrutura lógica casar com a estrutura de apresentação. Melhor ainda se a linguagem de autoria permitir a criação de tipos de composição com a semântica desejada pelo autor e que possam ser utilizados de acordo com a necessidade. Assim, a estrutura de apresentação de um documento pode se adaptar à sua estrutura lógica, e não o contrário. A linguagem NCL 2.0 oferece ao autor essas várias possibilidades, através do conceito de template de composição. A vantagem principal do uso de templates de composição, além da reutilização da estrutura, é a possibilidade de definição de uma semântica para uma composição. Dessa forma, tipos pré-definidos de composições, como os oferecidos pela linguagem SMIL, podem ser vistos como templates. Através do módulo XTemplate, novos templates de composição podem ser criados, generalizando os tipos de composição que a linguagem de autoria oferece. Essas mudanças de paradigma justificaram a especificação de uma nova linguagem modular, cujos módulos podem ser utilizados para estender os padrões existentes, incorporando novas facilidades. Com isso, a implementação do perfil SMIL+XTemplate é considerada o próximo trabalho futuro. Além da diferença principal sobre o uso de composições, outros comentários podem ser destacados na comparação entre NCL e SMIL 2.0. Além da possibilidade de especificar alternativas de conteúdo, através do elemento switch, idêntico ao que é oferecido por SMIL, NCL 2.0 permite a especificação de alternativas de exibição para um mesmo nó. Alternativas de exibição podem ser especificadas através do elemento descriptorswitch, que pode ser associado a um nó através de um elo, de uma composição ou pelo próprio nó, seguindo o cascateamento determinado na Seção 2. Na linguagem SMIL, as características de apresentação de um nó estão especificadas junto ao nó, exceto informações de layout espacial, que são definidas em separado. Para especificar alternativas de exibição para um mesmo nó em um documento SMIL, é necessário definir um elemento switch contendo repetições de um elemento com o mesmo conteúdo, associado a diferentes informações de exibição. Em NCL, basta especificar um único nó com o conteúdo desejado e associar um conjunto de descritores alternativos, representado por um elemento descriptorswitch. NCL oferece elos multiponto, representando relações com semântica causal ou de restrição, de acordo com o conector usado pelo elo. Além disso, uma mesma relação causal, por exemplo, pode relacionar eventos de diversos tipos, além dos tradicionais eventos de seleção e apresentação, normalmente contemplados. SMIL 2.0 só oferece

elos ponto-a-ponto, que podem ser disparados por eventos temporais. A possibilidade de usar eventos na especificação temporal de um documento SMIL 2.0 deu bastante flexibilidade à linguagem, comparada com sua versão anterior. Entretanto, para especificar relacionamentos complexos, o autor deve mesclar o uso dos contêineres temporais par, seq e excl com o uso de eventos, e ainda com o uso de elos, se for o caso, para especificar relacionamentos que envolvem a ocorrência de vários tipos de evento. Em NCL 2.0, uma relação, por mais complexa que seja, pode ser abstraída por um único conector e utilizada da mesma forma que uma relação bem simples. Outro comentário que merece destaque é sobre a especificação do comportamento temporal de objetos de forma flexível. Desde a versão 1.0 de NCL, que as durações de objetos na especificação de um documento podem ser definidas com valores ótimo, mínimo e máximo. Essa facilidade só foi incluída na linguagem SMIL em sua segunda versão. Além disso, NCL prevê a especificação de funções de custo [Rodr03] para guiar o formatador em possíveis ajustes temporais durante a apresentação do documento, visando minimizar a perda de qualidade. 6. Considerações Finais Esse artigo apresentou a versão 2.0 da linguagem declarativa NCL para autoria de documentos hipermídia. Sem dúvida, os módulos mais importantes de NCL 2.0 são os que tratam da definição de conectores e templates de composição. Esses dois módulos apresentam novas contribuições para linguagens de autoria hipermídia, considerando relações como entidades de primeira classe e permitindo a definição de uma semântica qualquer para um nó de composição. Para validação dos novos conceitos introduzidos, um parser NCL foi implementado de forma genérica, sendo o compilador NCL-NCM (objetos Java) uma instância desse parser. Esse compilador possibilitou a integração de NCL ao sistema hipermídia HyperProp [Much03], validando os novos conceitos. O próximo passo é o desenvolvimento de novas instâncias do parser, promovendo a integração de NCL a outros modelos, como diretamente ao modelo de execução do formatador HyperProp [Rodr03] e a modelos de players SMIL (obviamente com algumas restrições a funcionalidades oferecidas por NCL, devido às limitações de SMIL). Outro trabalho futuro é levar as facilidades introduzidas por NCL a padrões existentes, como já realizado para a linguagem XLINK [MuRS02]. Um trabalho já iniciado prevê a utilização de XConnector e XTemplate para estender funcionalidades no padrão SMIL, através da implementação do perfil SMIL+XTemplate. O módulo XConnector contempla a definição de relações de sincronização e referência, entretanto, o conceito de conector pode ser aplicado para definir qualquer tipo de relação. Por exemplo, pode-se definir um conector de versão para representar a relação ancestral/descendente usada em mecanismos para controle de versões de objetos, ou então um conector canal para representar o paradigma publish-subscribe usado em mecanismos de notificação de mensagens. Baseando-se em novos tipos de conectores, o módulo XTemplate pode ser usado para definir outras semânticas para composições, diferentes da semântica de sincronização temporal e espacial já disponível. Por exemplo, pode-se criar templates de composição para agrupar versões de um mesmo objeto e seu

grafo de derivação. O desenvolvimento de outros módulos para criação de outros tipos de relação é outro trabalho futuro. Apesar de NCL 2.0 ter acrescentado muitas novas facilidades em relação à versão 1.0, refinamentos sempre serão necessários. A especificação de novos módulos para permitir a definição de funções de custo para durações de componentes de um documento, possibilitando a realização de ajustes finos pelo formatador, também é prevista como trabalho futuro. Além disso, o suporte para computação automática de extremidades de elos, contemplando os antigos elos virtuais do modelo NCM [SoRM00], precisa ser construído. Referências [Alle83] Allen J.F. Maintaining Knowledge about Temporal Intervals, Communications of the ACM, 26(11), 1983, 832-843. [AMRS00] Antonacci M.J., Muchaluat-Saade D.C., Rodrigues R.F., Soares L.F.G. NCL: Uma Linguagem Declarativa para Especificação de Documentos Hipermídia na Web, SBMídia2000, Natal, RN, Junho 2000. [Mour01] Moura, M.S.A. Relações Espaciais em Documentos Hipermídia. Dissertação de Mestrado, Depto. de Informática, PUC-Rio, RJ, Agosto 2001. [Much03] Muchaluat-Saade D.C. Relações em Linguagens de Autoria Hipermídia: Aumentando Reuso e Expressividade, Tese de Doutorado, Departamento de Informática, PUC-Rio, Rio de Janeiro, Março 2003. [MuCS01] Muchaluat-Saade D.C., Colcher S., Soares L.F.G. Relações de Sincronização Espaço-Temporal Hipermídia Também Merecem Status de Primeira Classe, SBMídia2001, Florianópolis, SC, Outubro 2001. [MuRS02] Muchaluat-Saade D.C., Rodrigues R.F., Soares L.F.G. XConnector: Extending XLink to Provide Multimedia Synchronization, ACM DocEng'02, Virginia, USA, Novembro 2002. [MuSo02] Muchaluat-Saade D., Soares L.F.G. XConnector e XTemplate: Estendendo XLink para Aumentar Expressividade e Reuso, SBMídia2002, CE, Outubro 2002. [Rodr03] Rodrigues R.F. Formatação e Controle de Apresentações Hipermídia com Mecanismos de Adaptabilidade, Tese de Doutorado, Departamento de Informática, PUC-Rio, Rio de Janeiro, Março 2003. [SMIL01] Synchronized Multimedia Integration Language (SMIL 2.0), W3C Recommendation, Agosto 2001. [SoRM00] Soares L.F.G., Rodrigues R.F., Muchaluat-Saade D.C. Modeling, Authoring and Formatting Hypermedia Documents in the HyperProp System, ACM Multimedia Systems Journal, 8(2):118-134, Março 2000. [SoRM03] Soares L.F.G., Rodrigues R.F., Muchaluat-Saade D.C. Modelo de Contextos Aninhados versão 3.0. Relatório Técnico, Lab. TeleMídia, PUC-Rio, 2003. [XHTM01] XHTML 1.1 - Module-based XHTML, W3C Rec., Maio 2001. [XLIN01] XML Linking Language (XLink) Version 1.0, W3C Rec., Junho 2001.