- From: Thierry MICHEL <tmichel@w3.org>
- Date: Sat, 13 Aug 2005 00:26:35 +0200
- To: "Glenn A. Adams" <gadams@xfsi.com>
- CC: Bert Bos <bert@w3.org>, W3C Public TTWG <public-tt@w3.org>
Bert, If you require any further follow-up please do so, and if you are satisfied with the TTWG response, please acknowledge it by replying to this mail and copying the TTWG public mailing list: <public-tt@w3.org> <mailto:www-smil@w3.org?Subject=Re:%20Response%20to%20SMIL%202.1Last%20Call%20comment:%202005JanMar%2F0004.html&In-Reply-To=%3C42274EBF.5050108@w3.org%3E&References=%3C42274EBF.5050108@w3.org%3E> Regards, Thierry Michel Glenn A. Adams a écrit : >Dear Bert, > >Thank you for your comments, [1], on the DFXP Last Call >Working Draft. The TT WG has concluded its review of your comments and >has agreed upon the following responses. > >If you require any further follow-up, then please do so no later than >September 1, and please forward your follow-up to <public-tt@w3.org>. > >Regards, >Glenn Adams >Chair, Timed Text Working Group > >************************************************************************ > >Citations: > >[1] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0039.html > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >5.1) Why six different namespaces in one document format? It doesn't >seem like you can use any of them on its own. > >Response: > >In the context of TT AF, the division of namespaces is intended to >provide distinct name spaces in order to avoid collisions and to >provide functional context for a name. In this context, these >namespaces are designed to interoperate. In a more general context, >one could make use of the same namespaces in other contexts outside of >DFXP. There is no technical issue here. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >5.2) If it is important for an implementation to know the profile a >document conforms to, shouldn't the profile name be passed out of band >(as a MIME type parameter), instead of inside the document? A profile >is usually something you author to, but then neither the client nor >the server need to know that you do so; or it is something a client >uses for content negotiation (e.g., HTTP Accept header or TYPE >attribute on an HTML LINK element). It is not useful inside the >document, except perhaps for the Unix "file" command... > >Response: > >A "profile" or "version" could be passed out-of-band, but since DFXP >does not define a transport mechanism, such definition is more >appropriately defined in another specification in order to suit the >needs of that specification. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >5.2) In fact, the spec doesn't say what an implementation does with >profiles. I assume it doesn't do anything with it (unless perhaps if >the program is a validator). > >Response: > >DFXP explicitly does not specify a schema binding mechanism. >Conformance clause 3.2 sub-item 1 places this responsibility on a TT >AF Content Processor. Nevertheless, we recognize that some guidance be >provided to processor implementers; therefore, we will add informative >language suggesting that a processor may make use of the ttp:profile >parameter as a means for identifying the declared language subset >(profile). > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >5.3.1) Why lowerCamelCase even for names that are borrowed from other >specifications? XML names can contain dashes. > >Response: > >The TT WG has adopted a consistent convention for all names, and will >provide an informative annex indicating heritage of tokens and names, >indicating whether they had camel case normalization applied. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.1) EDITORIAL: s/express number/express the number/ > >Response: > >Will fix. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.1 until 6.2.13) All (not sure about one or two) of these >attributes can only occur on one element, viz., <tt>. So why are they >defined as global attributes (with a prefix)? > >Response: > >It is expected that these attributes may be used in different contexts >in AFXP; it is also possible that some of these may be useful in other >host languages that may choose to adopt features from TT AF. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.2) Where is the syntax of GPS time coordinates defined? I couldn't >find the definition in the spec and there is no reference either. > >Response: > >The phrase "time expressions" is formally defined in section 10.3. A >cross-reference will be added to make it clear that all time >expressions, whether GPS or not, make use of a consistent syntax. An >appropriate reference will also be added to permit semantic >interpretation of time expressions in the GPS time space. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.2) Are GPS time coordinates really needed? Their semantics are the >same as UTC, aren't they? What is the use case? > >Response: > >The semantics of GPS are distinct from UTC. The primary difference is >that UTC is adjusted for leap seconds, and may have seconds labeled >23:59:60 and may have minutes that are missing the second labeled >23:59:59. As of January 1, 1999, GPS - UTC = 13s. The use case for GPS >involves the fact that GPS is widely used in television broadcast in >the US for synchronization purposes. For example, the ATSC A/65 >Program and System Information Protocol (PSIP) standard is used to >transmit television program schedule information via terrestrial >digital transmission in the US, and PSIP makes use of GPS time >coordinates to express begin and end times for programming. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.2) It seems that there may be only one clockMode attribute per >document (if I interpret the note at the end of 6.2.13 correctly), but >unlike for the other attributes, there is no paragraph in this section >that says that clockMode may only occur on the <tt> element. > >Response: > >This was an oversight. An appropriate constraint will be added to be >constent with other time related attributes. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.3) Is the defaultLengthUnit attribute needed? In CSS, we found it >useful to have unitless numbers mean something specific, different >from a length, e.g., as a multiplier. That possibility is removed when >there is a default unit. Also, in a typical document there probably >aren't more than a dozen or so length values, so declaring a default >doesn't actually make the document shorter. > >Response: > >After careful consideration, the TT WG has agreed to remove both the >ttp:defaultLengthUnit and the ttp:defaultTimeMetric attributes and >instead require lengths and offet times to specify an explicit metric. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.3) The default is "pixels," but are they device pixels or px >units, as in XSL/CSS? > >Response: > >No longer applicable due to removal of ttp:defaultLengthUnit; however, >the larger question of what does "px" mean when specified in a length >will be addressed by adding language indicating that the XSL >definition applies. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.4) Same question: is defaultTimeMetric necessary? > >Response: > >After careful consideration, the TT WG has agreed to remove both the >ttp:defaultLengthUnit and the ttp:defaultTimeMetric attributes and >instead require lengths and offet times to specify an explicit metric. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.5) EDITORIAL: s/of document instance/of a document instance/ > >Response: > >Will fix. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.6) Is NTSC the only case where a frameRateMultiplier is necessary? >If so, then maybe a single keyword ("NTSC" on the frameRate attribute) >is enough, and a general multiplier is overkill. > >Response: > >NTSC is not the only case; furthermore, there are a variety of >operational usages in studios and in broadcast where >frameRateMultiplier may effectively be a continuous function. Use of >an enumeration would be overly restrictive and require constant >updating. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >6.2.6) EDITORIAL: s/MHz/Hz/ for the first occurrence in the note. > >Response: > >Will fix. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >7.1.1) Why must xml:lang be specified? Isn't omitting it the same as >defining it to be the empty string? > >Response: > >The goal is to strongly encourage authors and authoring systems to be >explicit about language. Specifying xml:space="" is not the same as >not specifying xml:space. The former is an explicit authorial >expression of "no default language"; the latter leaves authorial >intention unexpressed. We wish to enforce some intentional expression >even if it is "no default language". > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >7.1.1) Is xml:space necessary? You'll have to have style attributes >for space handling anyway, so why complicate matters by doing a half >job in XML? > >Response: > >We are not sure what is meant by "doing ... [the] job in XML". Our >understanding is that a compliant XML processor must always "pass all >characters in a document that are not markup through to the >application". Our understanding of xml:space is it permits the author >to express whether the application should use its "default white-space >processing mode" or should "preserve all white-space". Since we have >not introduced the full range of whitespace processing style >properties into DFXP, such as XSL's linefeed-treatment, >white-space-collapse, white-space-treatment, and >suppress-at-line-break properties, we instead rely upon use of >xml:space as an alternative mechanism for specifying authorial >intention regarding whitespace preservation. Nevertheless, we believe >it may be useful to re-express the algorithm specifying the meaning of >xml:space="default" to instead normatively reference the semantics of >the above mentioned XSL properties. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >7.1.3) Attributes begin, dur and end are on <tt> and on <body>. Are >they needed on both? > >Response: > >Distinct timing context is required on <tt> as opposed to <body> in >order to provide a timing container for <head> and thence to <layout> >and <region>, the latter of which can be animated. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >7.1.7) Is the <br> needed? You can also use two <p> elements if you >need two lines. > >Response: > >In XSL, <fo:block/> does not produce a block area since it has empty >content. Since TT AF maps <p/> to <fo:block/> semantics, two empty ><p/> elements from the TT namespace would map to: > ><fo:block/> <fo:block/> > >and thus not produce any visible side effect. > >In contrast, > ><p> <br/> </p> > >is defined to produce the same result as > ><fo:block> <fo:character character="
" >suppress-at-line-break="retain"/> </fo:block> > >We will review if additional clarification is required to express >these intentions. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >7.1.7) What happens if you put two <br> elements in a row, do you get >an empty line or not? > >Response: > >Given > ><p> <br/> <br/> </p> > >a compliant presentation processor produces the same results as: > ><fo:block> <fo:character character="
" >suppress-at-line-break="retain"/> <fo:character character="
" >suppress-at-line-break="retain"/> </fo:block> > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >7.1.7) Why does the <br> element have an xml:space attribute? Empty >elements don't contain spaces... > >Response: > >It was specified for symmetry sake (in order to be uniform on all >content elements). We will add an informative note that indicates that >it is effectively ignored if specified. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >7.2.3) Rule three seems to imply that the mark-up > > <p>one<span> two </span>three</p> > >is displayed as "onetwothree" without any spaces. Maybe you meant to >omit leading and trailing spaces from the <p> element only? > >Response: > >Based on a comment above, we believe it may be useful to re-express >the algorithm specifying the meaning of xml:space="default" to instead >normatively reference the semantics of the above mentioned XSL >properties. We will eiother re-express thus or correct the algorithm >(which we copied from SVG). > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.1.1) What happens if a DFXP document has a style PI? I assume a DFXP >application will ignore it (just like a generic XML viewer will ignore >the <styling> elements). > >Response: > >No normative semantic has been defined for any processing instruction; >therefore, a compliant presentation processor may ignore. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.2.1) The bullet list of elements that accept style attributes should >be non-normative (i.e., a note), because that information is already >known from earlier sections. > >Response: > >We believe there is no inconsistency in presenting the same normative >requirements twice, given the different contexts of the specification, >provided that there is no inconsistency between the requirements. We >believe there is no inconsistency at this time. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.2.10) The note says that a horizontal font-size is useful in systems >that have two fonts: normal and double-width. But do you expect a >horizontal font-size to work on any other system? or with any other >value than "1c" or "2c"? > >Response: > >We believe that specifying both horizontal and vertical sizes may >produce a continuously varying anamorphoic transformation on devices >capable of rasterizing fonts in a rectangular EM square. We do intend >to mandate that a given compliant presentation processor must support >either continuous anamorphic scaling of EM square or support some >discrete set of anamorphically-transformed font sizes. > >We also recongize that this feature constitutes an extension not >presently supported in XSL, and isn't adequately addressed by section >9.3.2 sub-items 6 and 7 (pertaining to populating XSL style >properties). Therefore, we will add additional normative language to >8.2.10 that expresses the intended semantics. > > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.2.16) The note says that a <p> is displayed on one line, unless a ><br> is used. But doesn't that also depend on wrapOption? > >Response: > >Good catch. Will fix. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.2.16) overflow in CSS/XSL has a value "scroll" but here it is >renamed to "dynamic." Why? An automatic scroll, such as the marquee >effect of "dynamicFlow," is a valid "scrolling mechanism" in XSL/CSS >terms. > >Response: > >We weren't certain if we could define "scroll" to mean "apply the >dynamic flow semantics defined in DFXP"; but given that you suggest >this we will change to using "scroll" and define "scroll" semantics >according to the dynamic flow features. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.2.17) "padding" allows one, two or four values. Why not three, as in >XSL/CSS? > >Response: > >We did not find the use of three values to be a particularly useful >feature, and did not need to support the limited subset of TT AF >expressed by DFXP. It is possible that AFXP will support the larger >subset. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.2.18) "showBackground" appears to be similar to 'empty-cells' in >CSS. Is there no way to merge them? > >Response: > >Perhaps, but we feel comfortable basing the usage in DFXP on the >current SMIL attribute whose name is "showBackground" [1]. > >[1] >http://www.w3.org/TR/2005/REC-SMIL2-20050107/layout.html#adef-showBackgr >ound > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.2.19) "textAlign" doesn't allow values "left" and "right" as in >XSL/CSS, although it is much easier for an author to write "left" than >"start" (or "end") when he means "left." Also, when converting from/to >other formats, it is easier if the value for textAlign in DFXP is a >direct translation of the corresponding value in the other format, >rather than a function of that other value and the "direction" >property. > >Response: > >We think that when at author writes "left" in a LRTB writing mode, >that they actually mean "start". We want to encourage the author to >express their logical intention. We are not certain if there is a >strong use-case for specifiying non-relative (absolute) text >alignment. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.2.20) CSS3 proposes a 'font-effect: outline' property to create >outline fonts, but it doesn't give control over the thickness of the >outline, let alone the amount of blur. Isn't 'font-effect: outline' >enough? > >Response: > >A number of TT WG members have a strong preference for providing the >ability to specify blur radius. There has been a request for >expressing separately the inner and outer color of the blur and >possibly gradient parameters to apply at the transition boudnary; we >chose a simple compromise that was modeled closely on the text-shadow >property of CSS2. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.2.22) The example is supposed to show that "visibility" can hide >text, but there is no text to hide... The first text only appears >after 1 second. > >Response: > >As it turns out, (1) the intent of this example was not "to show that >'visibility' can hide text", and (2) there is a bug in the example, in >that tts:visibility="false" on the paragraph means the paragraph (and >its children) will never be visible. The example DFXP document should >have read: > ><p region="r1" dur="4"> <span tts:visibility="hidden"> <set begin="1" >tts:visibility="visible"/> Curiouser </span> <span >tts:visibility="hidden"> <set begin="2" tts:visibility="visible"/> and ></span> <span tts:visibility="hidden"> <set begin="3" >tts:visibility="visible"/> curiouser! </span> </p> > >We will fix. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.3.6) The generic font family names suggest specific kinds of fonts, >but the spec effectively says to expect nothing. In that case, why >aren't they called "font1" to "font5"? Some help for implementers >seems useful. If an implementation has different fonts available, I >think users would like it if the fonts are mapped somewhat >intelligently. > >Response: > >Well it is either implementation dependent or not. We really want the >former. We prefer to let the market decide whether an implementation >does something sensible or not. To do something formal would require >introducing PANOSE concepts or equivalent which doesn't seem >particularly worthwhile. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.3.6) The generic font families are different from those in XSL/CSS. >Maybe DFXP doesn't need "fantasy" and "cursive," but it could have >kept > >"sans-serif" and "serif" without renaming them. Also, is the >difference "monospace-sans-serif" vs "monospace-serif" really needed? >Just one monospace font has been enough for all my uses (which weren't >subtitles, I admit). > >Response: > >The TT WG believes there are a number of examples of all combinations >of {monotype,proportional} x {sans-serif,serif} in use in >international subtitling applications that justify labeling all >combinations. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.3.11) The units px, em and c are defined syntactically, but what do >they mean? I assume px is as in XSL/CSS and em is the font-size, >because 8.2.10 mentions an "EM square" in relation to font-size. "c" >is probably the cell as defined by 6.2.1 cellResolution. > >Response: > >We will add a cross-reference to XSL definitions and expand further on >the definition of "c". But see more below on "em". > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >8.3.11) Is the em unit the vertical font size or the horizontal one? >Or does that depend on whether the length is used to measure something >horizontal or vertical? > >Response: > >We will elaborate that "em" in the context of a font that expresses an >anamorphic size has two interpretations depending on the context of >usage, i.e., depending on whether the length is being used to express >a distance along the block or inline progression dimensions. > >*********************************************************************** > >Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > >10.1.2) begin, end and dur attributes: what happens if they conflict? > >Response: > >At present, section 10.4 normatively references the semantics of SMIL >2 for the purpose of interpreting these attributes, as well as dealing >with possible conflicts (over-constraint scenarios). We are >considering fully inlining the timing interval semantics into the >spec, which is a greatly reduced subset of SMIL 2 timing semantics; if >we do this, then the usage and constraints on these attributes will be >fully articulated. > >*********************************************************************** > > > > >
Received on Friday, 12 August 2005 22:27:01 UTC