- From: Thierry MICHEL <tmichel@w3.org>
- Date: Fri, 14 Nov 2014 18:35:04 +0100
- To: Andreas Tai <tai@irt.de>
- CC: public-tt@w3.org
Dear Andreas, Khank for your approval to the TTWG proposal for ( LC-2975 LC-2976 LC-2973 LC-2977 LC-2978 LC-2974 LC-2980 LC-2981 LC-2982) There is one more comment for which you havn't responded - Comment LC-2979 https://www.w3.org/2006/02/lc-comments-tracker/34314/WD-ttml-imsc1-20140930/2979?cid=2979 Please review it carefully and let us know by email at public-tt@w3.org?subject=%5Bimsc%5D if you agree with it or not before 20 November 2014. Best regards, Thierry Michel On 14/11/2014 17:38, Andreas Tai wrote: > Dear Thierry, > > I have reviewed the solutions and agree with all of them. Thanks for > addressing my comments. > > Best regards, > > Andreas > > Am 13.11.2014 um 18:54 schrieb tmichel@w3.org: >> Dear Andreas Tai , >> >> The Timed Text Working Group has reviewed the comments you sent [1] on >> the >> Last Call Working Draft [2] of the IMSC 1.0 published on 30 Sep 2014. >> Thank >> you for having taken the time to review the document and to send us >> comments! >> >> The Working Group's response to your comment is included below, and has >> been implemented in the new version of the document available at: >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html. >> >> >> Please review it carefully and let us know by email at >> public-tt@w3.org?subject=%5Bimsc%5D if you agree with it or not before 20 >> November 2014. In case of disagreement, you are requested to provide a >> specific solution for or a path to a consensus with the Working Group. If >> such a consensus cannot be achieved, you will be given the opportunity to >> raise a formal objection which will then be reviewed by the Director >> during >> the transition of this document to the next stage in the W3C >> Recommendation >> Track. >> >> Thanks, >> >> For the Timed Text Working Group, >> Thierry Michel >> Philippe Le Hégaret >> W3C Staff Contacts >> >> 1. http://www.w3.org/mid/544E278A.9030901@irt.de >> 2. http://www.w3.org/TR/2014/WD-ttml-imsc1-20140930/ >> >> >> ===== >> >> Your comment on 3. Conformance: >>> ------------------------------ >>> 3. Conformance >>> ------------------------------ >>> The term "subtitle document" is not defined in IMSC 1 and TTML 1 but >>> used frequently in a normative context. It may be helpful to define it >>> in Section 2. >> >> Working Group Resolution (LC-2975): >> We have replaced the term "subtitle document" with "Document Instance", >> which is a defined term, at >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html >> >> >> ---- >> >> Your comment on 4.1 General: >>> ------------------------------ >>> 4.1 General >>> ------------------------------ >>> From IMSC 1: >>> "In addition, the Text Profile subtitle document SHOULD be associated >>> with the Image Profile subtitle document such that, when image content >>> is encountered, assistive technologies have access to its corresponding >>> >>> text form." >>> >>> As far as I could see there is no defined method to link a Text profile >>> >>> document to an Image Profile document through an element in the document >>> >>> themselves. So it may helpful to add that his has to be done through an >>> >>> external setting. >> >> Working Group Resolution (LC-2976): >> We have added the sentence "The method by which this association is >> made is >> left to each application" to the revised Section 5.1 at >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html >> >> >> ---- >> >> Your comment on 5.2 Foreign Element and Attributes A subtitle document >> MAY...: >>> It would be good to give more emphasis that a presentation processor >>> should not reject a document "with foreign namespace elements or >>> attributes". >>> >>> Examples for possible edits: >>> a) "...*The subtitle document SHALL be processed but* such elements and >>> >>> attributes may be ignored by the presentation processor or >>> transformation processor." >>> >>> b) "A *conforming* subtitle document may contain elements and attributes >>> >>> that are neither specifically permitted nor forbidden by a profile." >>> >>> It may be a good idea to align this paragraph with the section in TTML >>> 5.3.2. As far as I can see it is not explicitly forbidden to use the >>> IMSC namespaces for extensions. So either in IMSC 1 5.3 or somewhere >>> else an additional constraint may be added. >> >> Working Group Resolution (LC-2973): >> We have permitted ("may") elements and attributes that are not explicitly >> permitted or prohibited by a profile, and aligned with TTML1 the wording >> regarding namespace mutability. See revised Section 6.2 and last >> paragraph >> of Section 6.3 at >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html >> >> >> ---- >> >> Your comment on 5.7.3 itts:forcedDisplay itts:forcedDisplay allows the >> proc...: >>> ------------------------------ >>> 5.7.3 itts:forcedDisplay - value matrix >>> ------------------------------ >>> In general I would welcome a bit more text about the details of value >>> combinations. There is text for "displayForcedMode=true, >>> itts:forcedDisplay=false" but not for "displayForcedMode=true, >>> itts:forcedDisplay=true". Maybe a matrix would be helpful with >>> tts:visibilily (visible, hidden), displayForcedDisplay parameter (true, >>> >>> fase) annd itts:forcedDisplay (true, false). >>> >>> ------------------------------ >>> 5.7.3 itts:forcedDisplay - Informative Note >>> ------------------------------ >>> The first note could possibly be improved if it is noted that this has >>> an effect only if a "non-transparent background" is directly defined for >>> >>> the region (e.g. in most cases I have seen for the usage of EBU-TT-D the >>> >>> background will be applied through the content elements). >> >> Working Group Resolution (LC-2977): >> See revised second paragraph of Section 6.7.3 and Note 1 at >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html >> >> >> While NOTE 1 might apply only when non-transparent background is used >> on a >> region, the intent of the note is broader: warning authors that making >> all >> elements within a region hidden does not necessarily hide the region. >> >> ---- >> >> Your comment on 5.7.4 ittm:altText ittm:altText allows an author to >> provide...: >>> ------------------------------ >>> 5.7.4 ittm:altText - Optionality of attributes >>> ------------------------------ >>> For the XML Representation you may repeat the part from 2.3 TTML 1 where >>> >>> it states that bold-face attribute names are required and the others are >>> >>> optional (personally I would prefer the keyword "REQUIRED" after the >>> attribute name). Without that it may not be clear if the attributes are >>> >>> optional or required. >>> >>> >>> ------------------------------ >>> 5.7.4 ittm:altText - Typo >>> ------------------------------ >>> End of "Note:": Replace ". ." with "." >> >> Working Group Resolution (LC-2978): >> The specification now explicitly references the documentation conventions >> of TTML 1. >> >> See "Documentation Conventions" section and revised Section 5.7.4 at >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html >> >> >> ---- >> >> Your comment on 5.10 Features Unless specified otherwise,a subtitle >> documen...: >>> ----------------------------------- >>> 5.10 Features (Common features) #length-cell feature >>> ----------------------------------- >>> IMSC 1 states that the #length-cell feature shall not be used. The >>> line-padding extension uses the cell metric. Not sure if this causes a >>> problem. On the one hand the extensions are "outside" of TTML 1 on the >>> other hand they use the cell metric as defined by TTML 1. >>> >>> ----------------------------------- >>> 5.10 Features (Common features) -#length feature >>> ----------------------------------- >>> The #length feature includes the support of the "c" metric >>> (http://www.w3.org/TR/ttml1/#feature-length). So you may add a >>> restriction here. >> >> Working Group Resolution (LC-2974): >> Exception made to #length-cell for ebutts:linePadding. See revised >> #length-cell constraint at >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html >> >> >> ---- >> >> Your comment on 6.3 Features: >>> ------------------------------ >>> 6.3 Features (Text Profile) >>> ------------------------------ >>> #textAlgin: A reference to the definition of the "defaultRegion" in TTML >>> >>> 1 would be helpful. I assume that ony the TTML experts know what the >>> defaultRegion is (e.g. some implementers gave in a TTML document >>> "defaultRegion" as value for xml:id). >> >> Working Group Resolution (LC-2980): >> Default Region is now a defined term at >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html >> >> >> ---- >> >> Your comment on 8.2 Reference Fonts: >>> ----------------------------- >>> 8.2 Reference Fonts >>> ----------------------------- >>> A reference to presentation processors and transformation processors may >>> >>> be helpful. A presentation processor SHALL lay out the text according to >>> >>> the metrics and a transformation processor should use this metrics for >>> any calculation. >> >> Working Group Resolution (LC-2981): >> See clarified text at Section 7.3 at >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html >> >> >> ---- >> >> Your comment on B. Forced content (non-normative) Fig. 3 Illustration of >> th...: >>> ------------------------ >>> Annex B Forced Content >>> ------------------------ >>> A code example may be an illustrative help for the shown use case. >> >> Working Group Resolution (LC-2982): >> We have added Example 4 at >> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml-ww-profiles/ttml-ww-profiles.html >> >> >> ---- >> >> > >
Received on Friday, 14 November 2014 17:35:37 UTC