Re: [SMIL30 LC comment] 8. SMIL 3.0 smilText

 Dear Dr. Olaf Hoffmann  ,

The SYMM Working Group has reviewed the comments you sent [1] on the Last
Call Working Draft [2] of the Synchronized Multimedia Integration Language
(SMIL 3.0) published on 13 Jul 2007. 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.

Please review it carefully and let us know by email at www-smil@w3.org if
you agree with it or not before 02 nov 2007. 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 SYMM Working Group,
Thierry Michel
W3C Staff Contact

 1. http://www.w3.org/mid/200708061155.08689.Dr.O.Hoffmann@gmx.de
 2. http://www.w3.org/TR/2007/WD-SMIL3-20070713/


=====

Your comment on 8. SMIL 3.0 smilText:
> Hello SMIL working group,
> 
> some comments on chapter 8
> 
> 
> 8.3.1
> 
> 
> 'inherit
> The effective value of this attribute is used.'
> 
> -> What is an 'effective value'?
> -> Define or reference definition...
> -> or something like this:
> 'inherit
> The textWrapOption value of the parent element 
> is used.'?
> 
> --------------
> 
> typo?
> 
> 'This time is defines as being relative ...'
> ->
> 'This time is defined as being relative ...'?
> 
> 
> ---------
> 
> typo? (missing whitespace)
> 
> 'no preceding tev/clearelement'
> 
> ->
> 'no preceding tev/clear element'
> 
> ---------------
> 
> 'Examples'
> 
> -> shouldn't this be inside the informative box?
> 
> ---------------
> 8.3
> 
> smilText element content:
> 
> 'The smilText element may contain character content.'
> ->
> 'The smilText element may contain the elements tev, clear, br 
> or character content.'?
> 
> ---------------------------
> 
> 8.4
> 
> - The p element in XHTML has a semantic meaning
> of a paragraph and has nothing to do with styling, but
> with the meaning of the content. It is maybe not a 
> good idea to define it here without a meaning just for
> styling purposes. Wouldn't it be sufficient to note
> that a div can be within a div (but maybe not
> more then one level of nesting)?
> 
> - Another idea to get a little bit more meaning
> to the meaningless elements of this module is
> to add for example an attribute to smilText, div and span
> like textSemantics or textMeaning with a comma or
> space separated list as value with list items
> like h'digit', p, q, abbr, em, strong, pre, article, abstract,
> poem, stanza, line etc 
> (some more are available in the drafts for 'HTML5' or XHTML2), 
> partly similar to (X)HTML elements with semantic meanings
> or of semantic structures, currently not represented with
> (X)HTML elements, but nice for SMIL presentation.
> Author defined semantic value fragments could start with 
> '-' for example to expand this a little bit. 
> Of course authors can use (X)HTML right
> from the start to avoid meaningless text
> elements, but SMIL adds an additional
> feature like timing to the text, therefore there
> might be a reason to use this instead of
> (X)HTML. 
> 
> Therefore one can write 
> <div textMeaning="stanza em"> ... </div>
> or 
> <div textMeaning="p poem -concretePoetry"> ... </div>
> 
> This is not much more to implement, because there
> is no need to have a default styling for all these
> things, anyway the meaning of the content is
> machine readable and identificable as an author
> expects from a good markup language.
> If the author needs more than this
> 'minimal semantics', XHTML can be used, but even
> with ideas like 'microformats' this will not be
> much better for many text types as poems...
> And if CSS is available, authors can use this
> for styling too, using a selektor like
> div[textMeaning~="-concretePoetry"] or
> the styling attributes of smilText of course.
> Anyway these presentational attributes move
> smilText a little bit in the direction that
> presents text as a graphical object, as it is 
> in SVG, is this intended? If not, it would
> be sufficient to style it with CSS, isn't it?
> 
> 
> 
> 
> -------------------------
> div element:
> 
> 'This element accepts as content zero or more characters to which the 
> specified styling is applied.'
> ->
> 'This element accepts as content p or span elements or zero or more
> characters 
> to 
> which the specified styling is applied.'?
> 
> -> etc for the p element ...?
> 
> ----------
> 
> -> I think, textWrapOption is useful for div, this avoids further
> fragmentation of text, if the author needs for example a container
> of non wrapping text as pre in XHTML inside a larger text
> fragment. I think, without the textWrapOption for div the
> author has to divide his text in three smilText elements to
> get the same effect. But often this three fragments of text
> belong together as one text inside one large text container.
> 
> ---------------------
> 
> 8.4.1
> Example
> 
> typo?
> 
> "... as is shown in line 30'w ..."
> 
> -> what is the meaning of 'w?
> 
> 'Finally, the text element on line 35 illustrates that it is 
> possible to mix in-line and external text in a single document.'
> 
> -> line 36?
> 
> 
> ------------------------------
> 
> 8.5.1
> 
> textRate
> 
> 
> -> Because luckily the textFontSize is given in
> absolute or relative sizes, units like em, ex,
> glyphs are much more useful for authors to guess 
> some useful rate as px, because the relation between 
> the size of a glyph and a pixel is not known by
> the author. 
> To get something useful, we have to know, how
> reading works, maybe we need something like
> words per second to get an even more useful 
> guess for a textRate appropriate for a slow reader
> as glyphs per second...
> Maybe one has to ask some experts on psychology
> or behaviour research or something like this to 
> get some information about a useful unit for 
> textRate concerning typical reading strategies and 
> rhythms including a hint for authors about a
> useful value range for textRate for 
> accessibility reasons.
> Looking for this at wikipedia something like
> word fragments per second can be a useful
> unit - a word fragment is either a complete
> word if below say 10 glyphs or for longer
> words a fragment of the word of about 7
> glyphs.
> A typical range would be around 
> 2-5 word fragments per second for normal reading.
> Because it is more difficult to read moving
> text or specific fonts or sizes, this can
> be used as a hint for authors for a maximum
> value of a useful textRate.
> This applies only to alpabetical scripts,
> only in parts to syllabary or Scripts
> using symbols. Maybe for them the approximation
> withs glyphs per second is more useful...
> 
> Of course to get a smooth motion or a paced
> change of text position, viewers might
> transform the textRate again in an
> average value in px per second, because the
> viewer knows the size of a glyph in px and
> can determine a presentational textRate similar
> as this is done for font-size in CSS.
> 
> 
> -> lines per second continuous or in jumps are
> not very useful too, because the number of 
> glyphs or words in a line depend on the font 
> size and authors cannot guess some useful
> rate in lines per second, except maybe for
> poems with short stanzas and lines, in such a case
> it maybe very useful to give information
> about the rhythm of the poem with a textRate
> in lines per second, else this normally will 
> reduce readability of the text...
> 
> -> for accessibility reasons there should be
> a simple method for readers to manipulate 
> this textRate to their personal abilities in 
> each user agent, else such a feature is 
> more a method to torture readers...
> (I really dislike such moving text sections
> in movies in TV with tooooo tiny fonts and 
> toooo fast motion, one has to manipulate the
> player and has to use a lens/magnifier to 
> separate the glyphs from noisy pixels ;o)


Working Group Resolution:
As this comment contained a host of issues, each is considered
separately.

Issue: smilText does not define what the "effective value" for
the textWrapOption is when using 'inherit'.

Proposed resolution: The text has been refined to state that, unless
overridden, the inherited valued will be the default value (which is
'wrap').	
--------------
Issue: typo in text: This time is defines as being relative ...
Proposed resolution:	Corrected.
--------------
Issue: typo in text: no preceding tev/clearelement ...
Proposed resolution: Corrected.
---------
Issue:	typo in text: "Example should be part of informative box ...
Proposed resolution:	This is left as-is to preserve the ToC. Note that in
general, a more consistent labelling of informative sections has been
adopted.
---------------
Issue:	Section 8.3: The smilText element may contain character content,
plus smilText content.
Proposed resolution:	Text saying the the element contains mixed content.
(The content model is specified by the profile.)
---------------
Issue:	Section 8.4: Could the p element be extended to contain semantic
styling information? (Example: textMeaning="poem")

Proposed resolution:	This is beyond the scope of smilText. Semantic
meaning can be attached to a smilText element by using in-line metadata.
---------------
Issue:	The div element may contain character content, plus div, span and p
elements. (Similar definitions exist for the p element.)

Proposed resolution:	Text saying the the element contains mixed content.
(The content model is specified by the profile.)
---------------
Issue:	Add the textWrapOption as a legal attribute for div

Proposed resolution: 	textWrapOption is added as a suggested attribute for
div.
---------
Issue:			typo in 8.4.1 text: "... as is shown in line 30'w ..."

Proposed resolution:	Fixed.
---------
Issue:	typo in 8.4.1 text: "... the text element on line 35 ..."

Proposed resolution:	Fixed.
---------
Issue:	Using some higher-level values for textRate than simply pixels.

Proposed resolution: The definition of textRate and been refined to
include the value of 'auto' (for the typical case). In addition, leading
and trailing behavior is now supported via the textLT attribute.

----

Received on Tuesday, 23 October 2007 09:08:31 UTC