Olá,
Lendo a norma, cheguei as seguintes conclusões sobre avaliação de links e contexts.
1. Um context sleeping não deve ter seus links avaliados;
2. Um context está sleeping se todos os seus nós estão sleeping (mídias, contexts, switches, etc)
Não tenho aqui comigo a referência para os textos, por favor me corrijam se eu estiver errado.
Daí, que eu implementei no meu formatador o comportamento acima, e numa reescrita de alguns algoritmos precisei criar um teste de onEnd sobre uma mídia. Fiz um teste bastante ingênuo e ele não funcionou no meu formatador.
Daí então percebi que o body do documento precisava estar em estado sleeping depois da mídia parar e portanto depois disso nenhum link deveria ser avaliado.
Porém, fui testar isso na VM do Ginga e o comportamento na verdade é o que eu imaginei que seria quando criei o documento (sem pensar sobre o estado do context).
Estou colando o documento aqui, poderiam me dizer qual dos dois comportamentos é o correto?
<?xml version="1.0" encoding="ISO-8859-1"?>
1111 comentários
presentation event associated with a composite node represented by a
<body> or a <context> element stays in the occurring state while at
least one presentation event associated with anyone of the composite child
nodes is in the occurring state, or at least one context node child link is
being evaluated. It is in the paused state if at least one
presentation event associated with anyone of the composite child nodes is in
the paused state and all other presentation events associated with the
composite child nodes are in the sleeping or paused state. Otherwise, the
presentation event is in the sleeping state." Por isso o comportamento da VM Ginga está correto. O segundo link, no seu exemplo, deve ser avaliado e a media result_media deve ser apresentada. Luciana
> a avaliação onEnd do link ocorre simultaneamente com o stop ou em um tempo infinitesimal depois da ocorrência do stop (praticamente simultâneo). Não encontrei nada na norma dizendo isso. Encontrei apenas os seguintes trechos: <quote> NOTA
Quando uma condição “and” composta relaciona-se a mais de uma condição de disparo (isto é, uma condição
somente satisfeita em um instante de tempo infinitesimal – como, por exemplo, o final da apresentação de um objeto),
a condição composta deve obrigatoriamente ser considerada verdadeira no instante imediatamente após a satisfação de todas
as condições de disparo
</quote> <quote> Os eventos de atribuição permanecem no estado ocorrendo enquanto os valores de propriedade correspondentes
estiverem sendo modificados. Obviamente, eventos instantâneos, como eventos para simples atribuição de valor,
permanecem no estado ocorrendo apenas durante um período infinitesimal de tempo.
</quote> Que implicam somente que o final da apresentação é um tempo infinitesimal e que uma atribuição permanece no estado ocorrendo apenas durante um tempo infinitesimal. O segundo inclusive me parece simplesmente errado, já que é possível haver várias avaliações de onBegin de uma atribuição o que possivelmente poderia fazer o estado de ocorrendo se prolongar. E o primeiro me diz apenas que o evento possui um tempo infinitesimal, mas a ação de stop pode ter um tempo indeterminado (inclusive, em nenhuma implementação ele é infinitesimal e em alguns casos pode ser inclusive um tempo facilmente perceptível para o usuário). Não encontrei nada na norma que diga quando a avaliação é feita após uma execução de um link. Inclusive, uma troca de emails com o Luiz Fernando Soares me levou a entender que o tempo de uma ação é indeterminado que suas avaliações poderiam inclusive ocorrer em qualquer ordem com relação as condições do documento: O meu texto começa com "Isso significa ...", os outros dois são do professor. <quote>
2011/2/10 Felipe Magno de Almeida <felipe.m.almeida@gmail.com>:
> 2011/2/10 Luiz Fernando Gomes Soares <lfgs@...>:
> > 6) par/seq em CompoundAction
> > Em qualquer caso, no entanto, a exibição das mídias vai depender dos
> > retardos dos exibidores de mídia. Pode ser que um exibidor disparado
> > na frente de outro comece a exibição depois, por causa de seu retardo.
> > Um autor de documento tem de ter isso em mente.
> >
> > O procedimento, no entanto, não afeta o comportamento geral do ZIndex.
> > Não importa se proveniente de uma ação composta, par ou seq, o Zindex
> > define qual objeto sobrepõe o outro e, em caso de empate do ZIndex,
> > sobrepõe o conteúdo que começou a exibição (e não o comando da ação)
> > por último, conforme especifica a Norma na Seção 7.2.3.
>
> Isso significa que em quaisquer dos casos em seq ou par, em caso de
> empate, qual das apresentações aparecerá por cima é não-especificado e
> dependente da implementação? Exatamente e o autor da aplicação tem de estar ciente disso. Esse problema
só seria resolvido se o retardo de carregamento fosse zero, e isso é
impossível. Se um autor quer ter controle do aparecimento ele pode agir de
duas formas:
1) Usando vários elos com ações simples, onde eventos decorrentes da ação de
um elo trigariam as condições do próximo elo e assim por diante
2) Usando o parâmetro delay dos binds.
</quote> Isso tudo me leva a crer que os dois comportamentos são permitidos
pela norma (ou seja, é unspecified). O que é na minha opinião bastante
desagradável, já que criar aplicações NCL já é complicado como é
acreditando que podemos determinar uma dependência temporal (o que
não parece ser verdade). > Luciana Obrigado Luciana,
same reason discussed in the start instruction,
except for the event associated with the whole
content anchor, it is responsibility of the stopped-code span, before it
stops, to command the imperative-code player to change the state of any other
event state machine that is related with the event state machine associated to
the stopped code, and to inform if a transition associated with a change shall
be notified. Luciana