ISSUE-202: restoring metadata support to style element [TTML 1.0]

ISSUE-202: restoring metadata support to style element [TTML 1.0]

http://www.w3.org/AudioVideo/TT/tracker/issues/202

Raised by: Glenn Adams
On product: TTML 1.0

In a revision to TTML 1.0 between the last published CR [1] (on Feb 23, 2010) and the published PR [2] (on Sep 14, 2010), a technical change was made to make the content model for the <style/> element to be EMPTY instead of permitting metadata child elements (Metadata.class*). This change was described in the public TT reflector at [3], and the actual change can be seen in [4].

Although that email [3] describes the change as non-substantive, I wonder now if that was actually the case. In particular, it changed the language to prevent the inclusion of metadata items as children of <style/> elements, while they had been permitted before this change.

I'm raising the issue now because that change introduced an asymmetry regarding the ability to express metadata on non-metadata TTML vocabulary. Before this change, every non-metadata vocabulary item, even <br/>, permitted the use of metadata children. [N.B. This did not and does not hold for ttm:* vocabulary, since we did not want to have recursive metadata under ttm:* elements.]

Our original intent was that an author should be able to add metadata as children to any non-metadata element. As such, I think the change to exclude metadata from <style/> should be reconsidered, and that ability restored. The original suggestion in [3] that the reason for making it EMPTY was to potentially permit #PCDATA children in the future does not seem well motivated, since there is nothing preventing that even if metadata children are permitted.

The only question in my mind is whether to revert this earlier change in TTML 1.0SE or in TTML 1.1. It probably should not have been made between a CR and PR back in 2010, so we would be undoing that. However, one might argue undoing it would be a technical change, and that two wrongs don't make a right. I don't have a strong preference where we fix it, but I think we should fix it.

[1] http://www.w3.org/TR/2010/CR-ttaf1-dfxp-20100223/
[2] http://www.w3.org/TR/2010/PR-ttaf1-dfxp-20100914/
[3] http://lists.w3.org/Archives/Public/public-tt/2010May/0000.html
[4] http://dev.w3.org/cvsweb/2008/tt/spec/Attic/ttaf1-dfxp.xml.diff?r1=1.32;r2=1.33;hideattic=0;f=h

Received on Monday, 1 April 2013 01:36:32 UTC