Re: [Fwd: Last Call Announcement: DFXP 1.0]

Hi all,

The blog post is now at
http://blog.gingertech.net/2009/06/28/a-review-of-the-w3c-timed-text-authoring-format/
and my review email is at
http://lists.w3.org/Archives/Public/public-tt/2009Jun/0020.html . They
are lengthy, but shorter than the spec! :-)

Replies to Jack below...

On Mon, Jun 29, 2009 at 6:35 AM, Jack Jansen<Jack.Jansen@cwi.nl> wrote:
> One of the things I'm not sure about (and unfortunately I don't have the
> time to check out the whole document... 100+ pages for a subtitle format...)
> is their timing constructs. Originally (5 years ago) they started with a
> SMIL timing model. Then they toned it down. But: I have no idea where they
> stopped.
>
> A full SMIL timing model may be sub-optimal from a Media Fragments point of
> view. A SMIL document cannot be indexed uniquely with, say, #t=10,20,
> because what happens at t=10 may not be completely specified (being
> dependent on user input, for example). And even the underlying document has
> fully specified timing (i.e. no event-based timing or media-based timing at
> all) selecting the portion that corresponds to #t=10,20 would require a full
> SMIL parser and execution engine.
>
> For SMIL this is to be expected: asking for #t=10,20 for a time-based
> composition document is a bit like asking for #xywh=10,10,100,100 of an SVG
> document, it would non-trivial for simple cases and impossible in the
> general case.
>
> When we (we==the SYMM group) designed SMILText we've tried to be very
> careful to design a format that is linear in time, and with timing
> constructs only at the outer level. This was done specifically so that
> selecting the portion corresponding to #t=10,20 would not require a full
> SMILText parser, but simply inspecting the toplevel elements for their begin
> and next attributes and either copying or skipping the whole element and its
> substructure. (and giving up if event-based timing was used).

DFXP provides a lot of flexibility around the timing model, but as far
as I understand it, the time is pre-determined through the "start",
"end" and "dur" attributes, so the document can actually be layed out
in a linear fashion. It may however be something that is worth asking
about on the mailing list there again: is it possible to define a
document that cannot be linearised along time without further input?


> I'm pretty sure the same is true for CMML, it should also be possible to
> extract a temporal subsection without a full-blown CMML execution engine
> (but correct me if I'm overly optimistic here).

Oh yes. CMML was explicitly defined to be temporally linear. It's not
even possible to specify clip tags temporally out of order - which I
think is something that is possible for DFXP.


> I'm not convinced it's possible to extract a temporal fragment of a DFXP
> file without a full execution engine. But: maybe they've defined profiles or
> something in the mean time that allows this (fragmenting is not the only use
> case that would benefit from a subset that is linear and easily parsed and
> such).

That is a very good question. I've had to re-read the timing section
and I don't think the full SMIL timing model is supported (any
longer?). There are clear instructions for how to serialise a DFXP
document and apart from potential initial time offsets there are no
variable values possible. So, I think this may have changed from the
last time you looked at it.

Cheers,
Silvia.

Received on Sunday, 28 June 2009 22:18:35 UTC