emma:node anchoring on signal time axis

Dear W3C Multimodal working group,

I approached only recently EMMA and I have some problems understanding 
the temporal anchoring of an emma:node.

I would instinctively expect a node to correspond to what ISO 8601 
calls an "instant", a "point on the time axis".

With reference to paragraph 3.4, if I read correctly the document:

1. An emma:node can be anchored with absolute or relative timestamps. 
In the absolute mode, the optional emma:start and emma:end attributes 
seem to allow a duration, while in the relative mode, the optional 
emma:offset-to-start (with emma:duration not allowed) seems to force an 
instant status.
If, conceptually, a node is allowed to correspond to a segment of the 
signal, I would welcome a comment on the rationale for that. If  not, I 
would suggest to replace emma:start and emma:end with a single "time 
point"-like attribute or, at least, to forbid emma:end, implicitely 
adding ambiguity in the semantics of  emma:start.

2. An emma:arc implicitly asserts the existence of two nodes, but I 
would say that the temporal attributes of the arcs, if present, define 
those nodes. A node could be therefore defined more than once. I 
simplify the example in 3.4.2:
<emma:arc from="1" to="2"
emma:start="1087995961542" emma:end="1087995962042">flights</emma:arc>
<emma:arc from="2" to="3"
emma:start="1087995962042" emma:end="1087995962542">to</emma:arc>
Being node 2 the same, what if emma:end in the "flights" arc and 
emma:start in the "to" arc do not have the very same value?
Again, if this is conceptually allowed, I would welcome an explanation 
of the rationale. Otherwise, I would prefer enforcing a coherent 
description directly in the language instead of relying on validity 
checks. For example, restricting the "definition" of nodes inside 
node:element, i.e. forbidding timestamps in arcs.

I went through the document and the list archive and I wasnít able to 
find answers to these doubts. Nevertheless, I apologize if these points 
have already been addressed.
Thanks for your help and your work,

   Paolo Martini

Received on Thursday, 26 April 2007 01:19:36 UTC