Re: IMSC1 WD wide review and CR draft. ( LC-2975 LC-2976 LC-2973 LC-2977 LC-2978 LC-2974 LC-2980 LC-2981 LC-2982)

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