Copyright ©2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
These are the collected 2nd Last Call comments on Timed Text (TT) Authoring Format 1.0 Distribution Format Exchange Profile (DFXP), Second Last Call WD which were sent to the public Timed Text mailing list public-tt@w3.org (archives) and responses to those comments.
The 12 (2nd Last Call) comments have the following status (status on 18 Sept 2006):
Second LC Public Comments are as follows:
Notification of these Last Call responses were sent to all of the commenters and the Timed text list: http://lists.w3.org/Archives/Public/public-tt/
The status of the Disposition of comments for Timed Text DFXP FIRST Last Call are as follows:
The 15 (1st Last Call) comments have the following status (status on 15 Sept 2006):
Comment:
Hello public-tt, I didn't see a registration template for the application/ttaf+xml media type in http://www.w3.org/TR/2006/WD-ttaf1-dfxp-20060427/ Did I miss it? If not, please ensure that the next published specification includes such an appendix and that a textual copy of it is sent to the ietf-types@iana.org list inviting comments on the proposed registration. For details of the registration procedure in the IETF standards tree for W3C-produced media types, please see: http://www.w3.org/2002/06/registering-mediatype In the section entitled New Procedure: Registration template in spec, no RFC For examples of such a template, please see for example http://www.w3.org/TR/2004/WD-wsdl20-20040803/#ietf-draft http://www.w3.org/TR/SVGMobile12/mimereg.html -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response: Will add template.
The resolution is archived at:
http://lists.w3.org/Archives/Member/member-tt/2006Jun/0033.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Aug/0004.html
Comment:
Hello public-tt, section 3.2 Processor Conformance states: If the processor claims to support presentation processing in order to produce a rendition of TT AF content on a visual medium, then it must implement the region and line layout semantics defined by 9.3 Region Layout and Presentation and 9.4 Line Layout, respectively. In addition, the processor should satisfy the user agent accessibility guidelines specified by [UAAG]. section 9.3.2 Synchronic Flow Processing states: for each TT AF style property attribute in some computed style specification set that has no counterpart in [XSL 1.0], map that attribute directly through to the relevant formatting object produced by the input TT AF content element to which the style property applies; My question - it is not clear whether an XSL-FO processor which claims to be a TTAF- DFXP processor and claims to support presentation processing, but does not support any TT AF style properties that are not already in XSL 1.0, is a Conformant Processor per 3.2. Please clarify. If it would be conformant, are the extra TT AF style properties ignored? -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response: The intention is that the presentation processing defined by DFXP that extends beyond or differs from XSL 1.0 also be required by a conformant presentation processor. That is, a strictly XSL 1.0 conformant formatter would not be wholly adequate. The text will be clarified to make this intention more clear.
The resolution is archived at:
http://lists.w3.org/Archives/Member/member-tt/2006Jun/0033.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Aug/0003.html
Comment:
Hello public-tt, http://www.w3.org/TR/2006/WD-ttaf1-dfxp-20060427/ lists the Core Attributes as id, xml:lang, xml:space Given the difficulty of determining that an id is of type ID in the absence of a DTD or Schema, and given that external DTD subsets are optional in XML 1.0 and 1.1, and given that xml:id is intended precisely to provide an unambiguous ID attribute, could you please explain why the Core Attributes are not xml:id, xml:lang, xml:space ? http://www.w3.org/TR/2005/REC-xml-id-20050909/ xml:id Version 1.0 W3C Recommendation 9 September 2005 -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response: Accepted. id will be replaced with xml:id.
The resolution is archived at:
http://lists.w3.org/Archives/Member/member-tt/2006Jun/0033.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Aug/0006.html
Comment:
Hello public-tt, http://www.w3.org/TR/2006/WD-ttaf1-dfxp-20060427/ In 6.2.4 ttp:frameRateMultiplier the Note is very useful to explain the somewhat arcane NTSC frame rate. Is it correct to state that PAL (apart from PAL/M) has a ttp:frameRate of 25 and a ttp:frameRateMultiplier of 1:1 ? If so, it might still be useful to say so in a second Note and if not, it would be valuable to explain the PAL frameRateMultiplier in a Note. -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response: Yes, apart from PAL/M, it is as you indicate. A 2nd note will be added.
The resolution is archived at:
http://lists.w3.org/Archives/Member/member-tt/2006Jun/0033.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Aug/0002.html
Comment:
Hello public-tt, http://www.w3.org/TR/2006/WD-ttaf1-dfxp-20060427/ Section 7.1.7 br states: The br element denotes an explicit line break. When presented on a visual medium, the presence of a br element must be interpreted as a force line break Is that a break as in a carriage return (move to start of line), a line feed (move down one line) or both? In particular, does a sequence of two or more br elements produce a different visual effect to a single br? -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response: It is intended to have the same effect as the ASCII control codes CR followed by NL on a teletype device. Therefore, two br elements will indeed produce a different effect than a single br element on a compliant presentation processor. Additional language that clarifies this intention will be added.
The resolution is archived at:
http://lists.w3.org/Archives/Member/member-tt/2006Jun/0033.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Aug/0005.html
Comment:
Hello public-tt, I'm pleased to note that all colors are specified in the sRGB color space. Does TT AF DFXP express any conformance requirement regarding the fidelity of the colors when converting to and from DFXP? I am thinking not only of chrominance and white-point adaptation effects - which should be minimal for modern equipment given that sRGB uses the 709 phosphor chromaticities - but more for differing assumptions on headroom footroom, allowed colors, and corrections for flare, scene brightness, surround and other viewing condition effects. There is a useful discussion at http://www.srgb.com/srgb709compatibility.html How are sRGB and ITU-R BT.709-2 compatible? Basically I am wondering how much guidance should be given in this area such that reliable interchange between differing systems can be achieved. -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response: Other than the use of sRGB, DFXP intentionally does not specify conformance requirements on fidelity of color conversion from a source document to a DFXP document. At this point, we have not identified any requirements that would suggest adding this level of specificity.
The resolution is archived at:
http://lists.w3.org/Archives/Member/member-tt/2006Jun/0033.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Aug/0015.html
Comment:
Hello public-tt, In section 8.3.7 <flowFunction> The dynamic flow unit word must be interpreted as being dependent upon the language or writing system of the affected content. If the language or writing system is unknown or unspecified, then word is interpreted as follows: 1. If the affected content consists solely or mostly of Unified CJK Ideographic characters or of characters of another Unicode character block that are afforded similar treatment to that of Unified CJK Ideographic characters, then word is to be interpreted as if character were specified. 2. Otherwise, word is to be interpreted as denoting a sequence of one or more characters that are not interpreted as an XML whitespace character. Noting the "must" which is a testable conformance requirement, do the following paragraphs contain one word or two? <p>Hello World</p> <p xml:lang="en">Hello World</p> <p xml:lang="en">Hello World</p> <p xml:lang="ja">Hello World</p> <p xml:lang="ja">Hello World</p> <p xml:lang="ja">Masayasu Ishikawa</p> For a list of Unicode space characters, see for example http://www.cs.tut.fi/~jkorpela/chars/spaces.html -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response: Regarding your question, it depends upon whether the language or writing system is unknown or unspecified. If either of these cases hold, then, according to rule 2 above, each of your examples except the last would be interpreted as one word. The last would be interpreted as two words, presuming that the ' ' between "Masayasu" and "Ishikawa" is represented as #x20. In contrast, if the language or writing system is known, e.g., if xml:lang="en" is specified on the root element (and no override appears), then a word unit is specified in accordance of the rules of that language or writing system. DFXP does not specify these latter rules in an interoperable manner (as Unicode also does not specify).
The resolution is archived at:
http://lists.w3.org/Archives/Member/member-tt/2006Jun/0033.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Aug/0009.html
Comment:
Hello public-tt, 8.3.14 <string> A <string> expression consists of a sequence of characters where no character is a whitespace or quotation delimiter character. Syntax Representation � <string> <string> : ( char - { S | "\"" | "\'" } )+ I did not see a definition of 'char'. Please define the token char, preferably by reference to Unicode, appropriate productions from XML 1.0 or XML1.1, or CharMod part 1: Fundamentals. -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response: Accepted. The token "char" will be formally defined by referring to the references you cite.
The resolution is archived at:
http://lists.w3.org/Archives/Member/member-tt/2006Jun/0033.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Aug/0008.html
Comment:
Hello public-tt, 12.1 Element Vocabulary Many (but not all) of the elements seem to have Dublin Core equivalents. Was Dublin Core considered and rejected for this type of metadata? -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response:
Dear Chris,
I see that I failed to forward the response of the TT WG to your question (below) as follows:
<quote>
Yes, Dublin Core vocabulary was carefully reviewed for possible use, and the
decision of the group was that the intended use was sufficiently different to
warrant adoption. This comment was also received during the 1st Last Call,
the response to which was recorded at:
http://www.w3.org/2005/03/21/DFXPLastCallResponses.html#Issue9.
</quote>
You may also note the recent thread [1] on this reflector with Al Gilman, who had originally raised the same question during the 1st Last Call of DFXP [2]. I believe that Al has agreed with our final conclusion that:
"we found the analogy to SVG so compelling that we based these on that"
[1] http://lists.w3.org/Archives/Public/public-tt/2006Sep/0004.html
[2] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0038.html
If you would, please indicate if these responses represent a satisfactory conclusion to your comment.
Regards,
Glenn
The response is archived at:
http://lists.w3.org/Archives/Public/public-tt/2006Sep/0006.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Sep/0009.html
Comment:
Hello public-tt, In the informative references SVG 1.0 Jon Ferraiolo, Editor, Scalable Vector Graphics (SVG) 1.0, W3C Recommendation, 04 September 2001. (See http://www.w3.org/TR/2001/REC-SVG-20010904/.) Please note that SVG 1.0 is replaced by SVG 1.1: the 'latest version' link in SVG 1.0, http://www.w3.org/TR/SVG/ leads to SVG 1.1 Please replace this reference by SVG 1.1 Jon Ferraiolo, 藤沢 淳 (FUJISAWA Jun), Dean Jackson, Editors, Scalable Vector Graphics (SVG) 1.1 Specification, W3C Recommendation 14 January 2003 (See http://www.w3.org/TR/2003/REC-SVG11-20030114/ ) -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
TTWG Response: Accepted. Will update as suggested.
The resolution is archived at:
http://lists.w3.org/Archives/Member/member-tt/2006Jun/0033.html
TTWG response agreed by Requestor
http://lists.w3.org/Archives/Public/public-tt/2006Aug/0007.html
Comment:
Dear all, Enclosed you will find a PDF document containing some general remarks about TimedText DFXP. See http://lists.w3.org/Archives/Public/public-tt/2006Jul/att-0011/Some_general_remarks_about_Timed_Text.pdf Best regards, Samuel Cruz-Lara LORIA / INRIA Lorraine
Thank you for considering the DFXP formulation of the Timed Text Authoring Format. Perhaps some background will be useful for better understanding:
1. the requirement for parallel language representations of a single logical document in the context of a single document instance was discussed and included in TTAF1.0 requirements (see R201); explicit support for this was ruled out in DFXP, which is intended to satisfy a high priority subset of requirements that relate to interchange of legacy content; the conclusion of the WG was that it would be better to use multiple DFXP document instances to represent multiple language representations; it remains feasible to define a more complete profile of TTAF1.0 in the future, such as the AFXP (Authoring Format Exchange Profile) that was considered in earlier drafts, but, at this time, has taken a back seat due to insufficient member support;
2. no discussion occurred on the issue of how to explicitly synchronize content between multiple language instances; this potential requirement (which may be implied in your work) was not submitted for WG consideration;
3. requirement R203, regarding natural language association granularity, was intended to support only course grained linguistic attribution, and, indeed, xml:lang satisfied this basic requirement; it remains possible for a user of DFXP to make use of the ttm:role attribute while using extension tokens (i.e., "x-*") to denote application specific bindings;
4. the TTWG did perform a cursory review of the functionality defined by TEI (text encoding initiative) that could have formed the basis for additional requirements or solutions, however, no consensus was reached on adding any of its functionality;
The TTWG remains open to you (and others) bringing new requirements to the group for consideration; however, at this juncture, it is probably safe to say that DFXP itself is closed for the purpose of considering new requirements unless their absence negatively impacts the basic goals of DFXP.
Regards,
Glenn Adams
Chair TTWG
The response is archived at:
http://lists.w3.org/Archives/Public/public-tt/2006Jul/0012.html
TTWG response agreed by Requestor
None.
Comment:
Dear all, ** summary 1) I want to set a hook claiming that there is an accessibility interest in this topic ... but 2) I think I pretty much come down where Mike Dolan is on the mood of what DXFP should say (imperative (= normative) vs. informative). DFXP should include informative mention of accessibility guidelines for the use of color in captions, and this should be in such a way that authors of DFXP formatted content *and* those transcoding DFXP into delivery channels are aware that they have *both, independently* to pay attention to these guidelines. ** details 3) existence proof for accessibility interest -- WCAG 2.0 guidelines Success Criterion 1.4.1 http://www.w3.org/TR/2006/WD-WCAG20-20060427/guidelines.html#visual-audio-contrast 4) DFXP is targeted to be used for captions, that should meet accessibility guidelines as presented at the final User Interface. 5) Some of the service delivery chains that will use DFXP representations of timed text are Web delivery chains, including in the mobile space where we are not so impeded by legacy standards and channels. W3C takes an interest in providing end-to-end assurances of interoperability between the people speaking the material that gets included in captions and the people reading the captions. So at least for Web use cases, flowing down Human Factors requirements from the system level to the DXFP document are fair game. Nothing breaks access faster than long chains of services each of which says it's "not my problem." I think that this could be why the Working Group might prefer to duck this issue, but Cris in his Domain Lead role feels compelled to press the issue. * next steps; could we perhaps?: a) stipulate that DXFP docs will be used a lot to feed service delivery chains where they don't have a lot of control over the final color? b) So shouldn't we warn authors of this? c) Leave the color rep as is, presuming that this is fine enough, if faithfully rendered, to meet the great preponderance of fidelity needs. This format should afford color precision at a level which is modest overkill for the great preponderance of applications. d) Warn those who are going to use the color feature in this format about common system-level risks (illegible color contrasts, lack of user control, lack of definition in the controlling specs in the last mile distribution link,...) that bear on this aspect of their content; along with what known strategies they may wish to apply to mitigate these risks (pointers to accessibility guidelines, etc.)? Al
Al,
It is not clear from your message below whether you are making a comment
on the DFXP 2nd LC text, and if so, if you are expecting a response (since
the comment period had lapsed).
In any case, in reviewing the DFXP spec, I see that it does not cite WCAG1.0
in regards to content conformance. However, it does cite UUAG in the context
of processor conformance (section 3.2, item 5):
"the processor should satisfy the user agent accessibility guidelines specified by [UAAG]."
I would suggest we resolve this disparity by adding the following sentence at the end of section 3.1, item 5:
"In addition, the infoset should satisfy the web content accessibility guidelines specified by [WCAG]." and add a normative reference to WCAG.
Would this be a satisfactory resolution of your concerns?
Glenn Adams
Chair TTWG
The response is archived at:
http://lists.w3.org/Archives/Public/public-tt/2006Sep/0001.html
TTWG response agreed by Requestor ?
None.
Thierry MICHEL (tmichel@w3.org)
Last Updated:$Date: 2006/11/03 15:38:34 $