Re: DFXP LC Comments - Issue 10 Response; Bert Bos

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="&#x2028;"
>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="&#x2028;"
>suppress-at-line-break="retain"/> <fo:character character="&#x2028;"
>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