- From: Thierry MICHEL <tmichel@w3.org>
- Date: Tue, 9 Mar 2004 15:11:38 +0100
- To: <public-tt@w3.org>
Minutes of TT WG Meeting on October 1-2, 2003, Redmond, WA
Attendees
Glenn Adams (XFSI, Chair, Scribe) [GA]
Sean Hayes (MSFT) [SH]
Thierry Michel (W3C) [TM]
Erik Hodge (RealNetworks) [EH]
Geoff Freed (WGBH/NCAM) [GF]
Dave Singer (Apple) [DS]
Masahiko Kaneko (Microsoft) [MK]
Brad Botkin (WGBH/NCAM) - partial attendance, phone bridge
Gerry Field (WGBH/NCAM) - partial attendance, phone bridge
Regrets
David Kirby (BBC)
Markus Gylling (Daisy)
Markku Hakkinen (JSRPD)
Mike Dolan (Invited Expert)
************************************************************************
Agenda
************************************************************************
Day 1 (Wednesday, October 1, 2003)
0900 - 1030h Session 1
* Administrivia
- Plan Next Face to Face Meetings
* Action Item Review
* Work Plan Review
1030 - 1100h Break
1100 - 1300h Session 2
* Demos
* Example Development and Review
1300 - 1400h Lunch
1400 - 1530h Session 3
* General Review of Requirements Document
+ Collect Errata and Comments
* General Discussion of Profiles
1530 - 1600h Break
1600 - 1800h Session 4
* Brainstorm Content Requirement Solutions
Day 2 (Thursday, June 12, 2003)
0900 - 1030h Session 1
* Brainstorm Styling Requirement Solutions
1030 - 1100h Break
1100 - 1300h Session 2
* Brainstorm Timing and Animation Requirement Solutions
1300 - 1400h Lunch
1400 - 1530h Session 3
* Brainstorm Metadata Solutions
1530 - 1600h Break
1600 - 1800h Session 4
* Plan Minimum Profile Features
+ content
+ styling
+ timing and animation
+ metadata
* Wrap-Up
************************************************************************
Action Items Review
************************************************************************
Action: [TM] To help resurrect the bbcChildrensHospital2.mpg file.
[TM] needs to double check with W3C WebReq team.
Action: [GA] Publish draft agenda for F2F ASAP.
Done.
************************************************************************
Work Plan Review
************************************************************************
Oct 01 Solicit final comments on TT-AF-1-0-REQ from: MPEG (Systems),
IETF (AVT), 3GPP (SA4), SMPTE (D27-SDE), WAI (P&F), I18N,
SYMM IG, SVG WG.
Nov 15 Publish TT-AF-1-0-REQ as W3C Note
Nov 15 1st Internal Draft of TT-AF-1-0 beyond outline (available now)
Dec 15
Jan 15 1st Public Draft of TT-AF-1-0
Feb 15
Mar 15
Apr 15 2nd Public Draft of TT-AF-1-0
May 15
Jun 15 Adjust Schedule for Last Call
Action: [GA] To send notice to SMPTE, WAI, I18N, SYMM, SVG requesting
final comments on TT-AF-1-0-REQ by Nov 1.
Action: [DS] To send notice to MPEG, IETF, and 3GPP requesting
final comments on TT-AF-1-0-REQ by Nov 1.
Action: [MG] To send notice to Daisy requesting final comments on
TT-AF-1-0-REQ by Nov 1.
************************************************************************
Specification Development
************************************************************************
* TT Framework
Introductory material and common definitions.
* TT Core Vocabulary
* Content
* Intrinsic Text
* Extrinsic Text
* Logical Flowed Text
* Presentation Flowed Text
* Non-Flowed Text
* Hybrid Flowed and Non-Flowed
* Hyperlinking
* Embedded and Non-Embedded Graphics
* Embedded and Non-Embedded Fonts
* Descriptive Markup
* Conditional Content
* Style
* Aural Styling
* Visual Styling
* Timing
* Basic Timing
* Time Containers
* Sequential
* Parallel
* Exclusive
* Animation
* Scrolling
* Highlighting
* Transitions (Fading)
* Metadata
* DC
* TT Core Document Types
* Document Type 1
* Document Type 2
* Identify candidate document type usages in order to develop
examples.
* Profiles could be different document types but may also have
semantic subsetting and extensions.
* TT Extension Vocabulary(ies)
* TT Extension Document Type(s)
************************************************************************
Demos
************************************************************************
[GF] Presented demos of EIA608 and EIA708 data.
608/708 Modes
1. Pop-On Mode - presents entire caption block at once, and clears
entire block on arrival of new block material; can clear entire block
by using erase command. [GF] thinks that backspace doesn't work on
pop-on mode.
Action: [GF] Verify behavior of backspace commands with pop-on mode.
2. Paint-On Mode - presents character cell at a time, and clears entire
block on arrival of new material. Backspace and erase apply. Can
specify max # of rows (1-4).
3. Roll-Up Mode - presents character cell at a time, and scrolls up one
line upon arrival of new material after filling block. Can specify max
# of rows (1-4).
[BB] Verified that roll-up depth change causes top line(s) to disappear
immediately. Thinks that transparent spaces to specific locations is
causing erasure of lines in demo.
In G2 character code space (0x20) a transparent space is supported in
708. Can set pen-opacity on character by character basis. In 708 can
also set current font. Not clear what it means to change font then
write with space over current text, i.e., different widths might cause
problems. Would probably have to use mono-space font to have this work.
Backspace doesn't have affect in pop-on mode. Must be using roll-up
or paint-on mode.
708 Control Codes of Interest
C0 0x08 BS Backspace
C0 0X0C FF Form-Feed
C0 0x0E HCR Hard Carriage Return (?); not documented in 708
C0 0x20 SP Space
G1 0xA0 NBS Non-Breaking Space
G2 0x20 TSP Transparent Space
G2 0x21 NBTSP Non-Breaking Transparent Space
Action: [BB] To determine semantics of form-feed (FF) and report back.
To also check on HRC (0x0E) semantics.
************************************************************************
Example Development
************************************************************************
1. Using 'logical flowed text vocabulary': has content and timing
semantics, with all style applied externally or by reprocessing (e.g.,
using XSLT) to produce presentation flowed text vocabulary, or,
if internally expressed, then perhaps using external vocabulary.
<head>
<stylesheet units="cell">
<style id="default" select="*">
<prop name="color">black</prop>
<prop name="visibility">false</prop>
</style>
<style id="region1">
<prop name="x">10</prop>
<prop name="y">10</prop>
<prop name="width">20</prop>
<prop name="height">4</prop>
</style>
<style id="region2">
<prop name="x">20</prop>
<prop name="y">20</prop>
<prop name="width">20</prop>
<prop name="height">4</prop>
</style>
<style id="speaker1" use="region1">
<prop name="visibility">true</prop>
<prop name="text-align">center</prop>
</style>
<style id="speaker2" use="region2">
<prop name="visibility">true</prop>
<prop name="text-align">left</prop>
</style>
</stylesheet>
<timing units="frame">
<par>
<cue select="id('p1')" begin="0" end="10" apply="speaker1"/>
<cue select="id('p2')" begin="10" end="20" apply="speaker2"/>
<cue select="id('p3')" begin="20" end="30" apply="speaker1"/>
</par>
</timing>
</head>
<body>
<div class="speaker1">
<p id="p1">
<span id="s1">Subtitle Block 1 - Line 1</span><br/>
Subtitle Block 1 - Line 2<br/>
Subtitle Block 1 - Line 3
</p>
<p id="p3">
<span id="s3">Subtitle Block 3 - Line 1</span><br/>
Subtitle Block 3 - Line 2<br/>
Subtitle Block 3 - Line 3
</p>
</div>
<div class="speaker2">
<p id="p2">
<span id="s2">Subtitle Block 2 - Line 1</span><br/>
Subtitle Block 2 - Line 2<br/>
Subtitle Block 2 - Line 3
</p>
</div>
</body>
[EH] So you're happy that with no time, then nothing shows up?
[DS] We're doing timed text: no time, no text!
2. Using 'presentation flowed text vocabulary': has content and timing
semantics and must have block layout semantics.
<stylesheet units="cell">
<region id="region1">
<prop name="x">10</prop>
<prop name="y">10</prop>
<prop name="width">20</prop>
<prop name="height">4</prop>
</region>
<region id="region2">
<prop name="x">20</prop>
<prop name="y">20</prop>
<prop name="width">20</prop>
<prop name="height">4</prop>
</region>
<style id="default">
<prop name="color">black</prop>
<prop name="visibility">false</prop>
</style>
<style id="speaker1">
<prop name="region">region1</prop>
<prop name="visibility">true</prop>
<prop name="text-align">center</prop>
</style>
<style id="speaker2">
<prop name="region">region2</prop>
<prop name="visibility">true</prop>
<prop name="text-align">left</prop>
</style>
</stylesheet>
<flows style="default">
<flow style="speaker1">
<block id="b1" dur="10">
<inline color="red" dur="3">Subtitle</inline> Block 1 - Line
1<br/>
Subtitle Block 1 - Line 2<br/>
Subtitle Block 1 - Line 3
</block>
<block id="b3" dur="10">
Subtitle Block 3 - Line 1<br/>
Subtitle Block 3 - Line 2<br/>
Subtitle Block 3 - Line 3
</block>
</flow>
<flow style="speaker2">
<block id="b2" dur="20">
Subtitle Block 2 - Line 1<br/>
Subtitle Block 2 - Line 2<br/>
Subtitle Block 2 - Line 3
</block>
<block src="#b2"/>
</flow>
</flows>
Note that in this example, one block of text content is obtained
by indirect reference to logical flowed text content file.
Default timing semantics as follows:
* distinct flows run in parallel
* flow has sequential time containment semantics
* flow has time action semantics of
[SH] What is difference between this mode and logical mode?
[DS] Logical mode conceptually requires processing entire document
in order to determine presentation and temporal orders; while in
this presentation mode, the presentation and temporal orders have
been determined (compiled), and thus are streamable while the
former is not necessarily streamable.
3. Using 'non-flowed text vocabulary': has timing and block layout
semantics, but no content semantics.
<area id="r1" units="cell" font="f1">
<area id="b1" x="10" y="10" width="20" height="4">
<glyphSequence src="content.xml#s1"/>
<glyphSequence y="1">Subtitle Block 1 - Line 2</glyphSequence>
<glyphSequence y="2">Subtitle Block 1 - Line 3</glyphSequence>
</area>
<area id="b2" x="20" y="20" width="20" height="4">
<glyphSequence src="content.xml#s2"/>
<glyphSequence y="1">Subtitle Block 2 - Line 2</glyphSequence>
<glyphSequence y="2">Subtitle Block 2 - Line 3</glyphSequence>
</area>
</area>
Note that in this example, two sequences of text content are obtained
by indirect reference to logical flowed text content file.
How to denote glyphs for which no unicode mapping exists:
<glyph x="" y="" glyphId="0x0001"/>
************************************************************************
TT-AF-1-0-REQ Comments
************************************************************************
S003, 1st note, change "serves as timebase master" to "may serve as..."
R109, 1st note, "exhuastive" typo
R110, 1st note, "stramable" typo
R111, 2nd bullet, change "Adaption" to "Adaptation"
R391, change order to CSS3, CSS2.1, CSS2
Acknowledgments, "Gerry Field" not "Fields"
References, upgrade Unicode 3.2 to Unicode 4.0
************************************************************************
Content Requirement Solutions
************************************************************************
R200 - use XML
R201 - use xml:lang with RFC3066 compliant codes
Action: [GA] Request XML Schema WG revise definition of xs:Language to
use RFC3066.
R202 - support Unicode 4.0
R203 - permit xml:lang on phrasal, character, glyph vocabulary items
R204 - use XML numeric character references or XML named general
entities (as char refs)
R205 - use a XLink vocabulary with any element type that can contain
#PCDATA content, such that if an XML document is referenced, then a
fragment component shall use XPointer, and if another content type is
referenced, then a fragment component is interpreted using externally
defined specifications associated with that content type;
Issue: Whether to use XLink vocabulary, e.g., as used consistently by
SVG, or use "src" attribute as apparently will be done in XHTML2?
Note that XLink can reference multiple top level resources by using
child elements that employ XLink vocabulary.
Issue: Whether to use IRIs instead of URIs? Note: XPointer and
Namespaces in 1.1 use IRIs?
[1] http://www.w3.org/International/iri-edit/draft-duerst-iri-02.txt
Resolution: to tentatively use XLink, IRIs, and XPointers subject to
further study.
R206 - use XML
R207 - use a switch element type with generic test expression
attribute, such that the value can take arbitrary predicates, possibly
using XPath predicate syntax (or not); permit nesting
(cond
((equalp x 'foo') (foo))
((equalp x 'bar') (bar))
('t (baz)))
Do equivalent to above.
Might want to consider some predefined predicates, like
system('property-name') == ...
e.g., system('caption') == 'en'
system('bandwidth') > 1000000
system('color-depth') == 8
system('horizontal-resolution') > 640
...
Action: [SH] Will investigate use of media queries in this context and
report back.
Overall Example
<tt:switch>
<p test="system('caption')=='en'">English Caption</p>
<p test="system('bandwidth')>10000000" src="BigStuff.txt"/>
<p>Sorry, no non-English bandwidth</p>
</tt:switch>
Support usage where switch statement is implied as follows, such that
each element with test attribute whose parent is not switch has an
implied switch that wraps that one element.
An Example without Explicit Switch
<div>
<p test="system('caption')=='en'">English Caption</p>
<p test="system('bandwidth')>10000000" src="BigStuff.txt"/>
<p>Don't care if english or high bandwidth.</p>
</div>
The above is equivalent to:
<div>
<switch>
<p test="system('caption')=='en'">English Caption</p>
</switch>
<switch>
<p test="system('bandwidth')>10000000" src="BigStuff.txt"/>
</switch>
<p>Don't care if english or high bandwidth.</p>
</div>
Note that test attribute can appear on switch element as well.
Multiple predicates are handled internally to test expression language,
e.g.,
test="system('caption')=='en' && system('bandwidth')>10000000"
R208 - use solution for R209 or R210
R209 - use "body", "div", "p", and "span" elements (in our TT
namespace) use <br/> for forced line break for intrinsic text, for
extrinsic text it is determined by content format of extrinsically
referenced content type
Tentatively support "role" attribute on these element types
Issue: Should we use "class" instead of "role"?
[DS] Need to document what to do if extrinsically referenced text
content is
plain text.
[GA] Use relevant parts of Unicode 4.0 Section 5.8 Newline Guidelines
Rules 2
and 2b as apply to line separators paraphrased as follows:
R2 Always interpret LS (0x2028) as line separator
R2b In "plain text", interpret any NLF the same as line separator (LS)
R210 - use "flow", "blockContainer", "block", "inlineContainer",
"inline", "char", "region", "viewport"; use <br/> for forced line break
Issue: Should we use <character code="0x000A"/> instead of <br/>
for forced line break? This is how it is expressed with XSL FO.
Alternatively, can use:
<inline style="break-after:line">This is
<inline style="font-weight:bold">intended</inline>
to be a line.</inline>
Resolution: Allow <character code="0x000A"/> and break-after/before
style? Don't permit <br/> in presentation flowed text vocabulary usage.
[DS/EH] How about 
? [GA] Dangerous to assume it will survive
vagaries of XML space normalization processing.
Open Issue: Need to define what semantics if 
 does come through
(as well as other NLF sequences).
[GA] Probably need to define xml:space as preserve for all content
element types.
Issue: Should we use exact same names as XSL-FO vocabulary?
blockContainer vs block-container
inlineContainer vs inline-container
ch vs char vs character
Resolution: Be internally consistent in naming conventions, adopt
camelCasing with first letter being lowerCase. Abbreviate where it
makes sense, but in general don't. Use abbreviations only for very
common constructs. Stay with "character" since it won't be used
frequently. However, use "code" attribute with "character" element.
Issue: If we need hierarchical definition of regions, e.g., due to
nested regions, then we should express this hierarchy separately from
flows hierarchy and reference regions from flows. Otherwise, if we have
a flat region model, i.e., regions all defined relative to origin of
display medium, then it would suffice to incorporate region definition
as style properties on each flow. We need to determine which of these
to support?
Note: XSL FO, from which region/viewport are "borrowed", don't define a
general nested hierarchy, unlike SMIL 2 which does.
[SH] Region and viewport really belong to style vocabulary.
Issue: Whether to define the region and viewport vocabulary in content
section or in style vocab section?
Resolution: 1. define style vocabulary such that we explicitly indicate
which content vocabulary the style vocabulary can be applied to. 2.
consider viewport and region as style vocabulary rather than content
vocabulary since it appears to be applicable to both logical and
presentation oriented content vocabulary.
R211 - specify relationship implied by R211 in text of spec as
informative material; show system model that maps from logical content
space to presentation content space to non-flowed content space
R212 - structure modules and document type(s) as follows:
Resolution:
Define Modules
+ header
+ logical content
+ presentation content
+ non-flowed content <N.B. now treat as distribtion format, see
R214/215 below>
Define Document Type that uses generic content model as follows:
head, interleave(body?,flows?), distributionFormat*
where "interleave(body?,flows?)" means zero or one of each of body,
flows in any order
define distributionFormat as generic container for either inline
(embedded) or external distribution format of content, such as SVG.
R213 - TTWG now considers this to be out-of-scope for TT-AF and more in
the realm of a DF; therefore, describe at least one potential
distribution format, specifically, SVG;
R214 - document possible mapping to SVG vocabulary
R215 - use document type model shown above in R212, don't allow
intermixing at low level of granularity;
R216 - use SVG link module as model mutatis mutandis (consider needs
for links from images or image maps)
R217 - use SVG image module as model; permit "data:" URI, but define
content model that permits base64 encoded image; ensure schema permits
arbitrary content element types that admit foreign namespaces for
representing other image types in XML format, e.g., MathML, SVG, etc.
see RFC2397 for data: uri definition
Examples:
<image src="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
hhx4dbgYKAAA7">
<title>Larry</title>
</image>
<image type="image/jpeg">
<data encoding="base64">...base64 encoded data...</data>
</image>
<image type="image/svg">
<svg:svg xmlns:svg="http://www.w3.org/2000/svg">...</svg:svg>
</image>
R218 - same as R217 but no child "data" element
R219/R220 - follow "image" model for embedded and non-embedded, suggest
use of following MIME types:
* application/font-tdpfr
* application/x-font-truetype
Action: [DS with help of Paul Nelson and Peter Lofting] Write RFC to
register appropriate opentype/truetype font types as MIME media types,
suggest model of "application/font-<font-type-name>", e.g.,
"application/font-truetype".
<font id="MyFontFamily" src="http://www.apple.com/fonts/Zapfino.ttf">
<title>A Zapfino Production</title>
<metadata>
<ttf:unicodeRanges xmlns:ttf="...">
<range start="0x0020" end="0x007E"/>
<range start="0x00A1" end="0x00FF"/>
<range start="0x4E00" end="0x4E01"/>
</ttf:unicodeRanges>
<ttf:cmapOverride xmlns:ttf="...">
<entries start="0x4E00">0x0100 0x0101</entries>
</ttf:cmapOverride>
</metadata>
</font>
[DS] Hmmm...
[GA] Above is an example of possible metadata with fonts.
R221 - Support use of arbitrary foreign namespaces such that if a given
TT-AF processor does not recognize such a namespace, then the any
#PCDATA or TT namespace descendants shall be treated as if they were
immediate descendants of their nearest ancestor element that is a TT
namespace element.
<div>
<p>
<tei:u who='hamlet'>To be... <tei:pause/> or not to be... </tei:u>
<tei:vocal who="cat" desc="meows">
<audio type="audio/basic" src="audio.aiff"/>
</tei:vocal>
</p>
</div>
Require the universal use of "id" attribute with type xs:ID with any
foreign namespace elements.
Issue: Probably want to permit in logical content mode the selection of
content based on generic XML features of non-TT namespace descriptive
markup, e.g., for applying style and timing semantics, in which case an
appropriate TT container element shall be implied based on nearest
ancestor TT namespace element.
Example:
<div>
<foo:block id="b1">
<p>
<foo:inline id="i1">abc</foo:inline>
</p>
</foo:block>
</div>
Given a style/timing that selects b1 or i1 in order to apply
style/timing, then imply following:
<div>
<div id="b1">
<p>
<span id="i1">abc</span>
</p>
</div>
</div>
[DS] This seems complicated. Require user to wrap themselves using our
vocab and select based on vocab.
Resolution: Describe how to have style/timing rules that use predicates
and selectors that depend on structure and attributes of foreign
namespace vocabulary and still produce well-defined semantics in terms
of applying style/timing properties.
R222/R223 - follow "image" model for embedded and non-embedded;
R29X - accept as is
************************************************************************
Styling Requirement Solutions
************************************************************************
R300 - see R301
R301 - (1) distinct attributes, use named style parameters module
application of naming conventions (see below); (2) support "style"
attribute using CSS style declarations syntax; (3) inline stylesheets,
define our own vocabulary, e.g.,
* <stylesheet id="" media="">...</stylesheet>
; similar to CSS stylesheet @media rule
* <style id="">...</style>
; similar to CSS declarations
* <property name="...">value</property>
; similar to CSS property with value
<stylesheet units="cell">
<head></head> ; used for internal/external stylesheets
<style id="default" select="*">
<prop name="color">black</prop>
<prop name="visibility">false</prop>
</style>
</stylesheet>
Issue: What naming convention to apply for style property names? CSS
and XSL use hyphenated names. If we expose these names as attributes as
well, then we may have conflict with camel casing convention.
Resolution: Use camelCasing for attribute names and internal usage of
style parameters. For stylesheet languages, either embedded or
external, then require the user of some language to specify mapping as
required. Define recommended mapping for CSS and XSL in informative
annexes.
R302/R303 - use same approach as above, with stylesheet element being
root, possibly with some header and/or metadata elements
R304 - define cascading rules to deal with prioritzation
Issue: Need to think about cascading semantics; how to express, how to
apply, etc. Possibly use CSS semantics here as well.
R305 - adopt CSS aural style property semantics for following:
+ azimuth
+ cueAfter
+ cueBefore
+ cueDuring (CSS play-during)
+ elevation
+ pauseAfter
+ pauseBefore
+ pitch
+ pitchRange
+ richness
+ speakMode (CSS speak)
+ speakNumerals
+ speakPunctuation
+ speechRate
+ stress
+ voiceFamily
+ volume
[SH] May want to consider use of SSML.
[GA] We will entertain all proposals.
R306 - yes, do support
Issue: For border shorthand properties, do we also want non-shorthand
for expressing width, style, color independently?
Resolution: add individual non-shorthand border properties.
Issue: for origin property, it appears to be somewhat unnatural to have
to express in terms of absolute left, right, top, bottom such that this
is portable for different writing modes; the intuitive definition is
that origin(10px,10px) is 10px down and right from container in LR-TB
writing modes, but that this is 10px down and left from container's top
right vertex in RL-TB writing modes, etc. In other words, is the
vertex for the reference point of the containing area and the vertex
for the reference point of the contained area always the TOP,LEFT
vertex or does this depend on the writing mode, e.g., TOP,RIGHT for
RL-TB and TOP,RIGHT for TB-RL?
Action: [GA] Discuss with XSL WG as required to resolve.
[DS] How about glyph orientation?
[GA] Apparently we missed "glyph-orientation-horizontal" and
"glyph-orientation-vertical".
Resolution: Add XSL glyph-orientation-* style properties to TT-AF spec.
R307 - walked through examples from John Birch; appears to be
internally self-consistent, raises a few issues such as:
* jump vs smooth scrolling parameters
[DS] trick w.r.t starting smooth scrolling; need to start scrolling
just in time for when you want to display new content; [SH] only a
problem if you don't have lookahead;
[SH] should this apply to blocks in flows as well as inlines within
blocks; need to generalize values for modes as "word" and "fragment"
doesn't apply in block;
[DS] should be able to specify scrolling on flow, block, line, span
(fragment), word, character, pixel; [SH] also continuous scroll mode
* needs integration with 3GPP scroll-in, scroll-out, scroll-delay and
scroll-direction
* how to allocate timing for scrolling operation w.r.t. fill and
inter-fill intervals (N.B. fill interval means "read interval" and
inter-fill interval means "insertion interval"
* maybe want to better define fill/read interval and
inter-fill/insertion interval, some possibilities:
(1) period and duty cycle (percent time stable/movement)
(2) period of stable and period of movement
* [EH] may want to consider using animation to solve this; [GA]/[SH]
thinks this may be too low level of expression
* fill direction needs to consider filling in both block and inline
progression directions;
R390 - implement in TT-AF spec
R391 - use to resolve semantic definitions in TT-AF
R392 - we haven't yet defined (and don't intend to define) any
stylistic oriented element types
************************************************************************
Timing and Animation Requirement Solutions
************************************************************************
Insufficient time to discuss.
************************************************************************
Metadata Requirement Solutions
************************************************************************
Insufficient time to discuss.
************************************************************************
Profiles
************************************************************************
Insufficient time to discuss.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
START SUMMARY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*** RESOLUTIONS ***
Resolution: to tentatively use XLink, IRIs, and XPointers subject to
further study.
Resolution: Allow <character code="0x000A"/> and break-after/before
style? Don't permit <br/> in presentation flowed text vocabulary usage.
Resolution: Be internally consistent in naming conventions, adopt
camelCasing with first letter being lowerCase. Abbreviate where it
makes sense, but in general don't. Use abbreviations only for very
common constructs. Stay with "character" since it won't be used
frequently. However, use "code" attribute with "character" element.
Resolution: 1. define style vocabulary such that we explicitly indicate
which content vocabulary the style vocabulary can be applied to. 2.
consider viewport and region as style vocabulary rather than content
vocabulary since it appears to be applicable to both logical and
presentation oriented content vocabulary.
Resolution: Define Modules
+ header
+ logical content
+ presentation content
+ non-flowed content <N.B. now treat as distribtion format, see
R214/215 below>
Define Document Type that uses generic content model as follows:
head, interleave(body?,flows?), distributionFormat*
where "interleave(body?,flows?)" means zero or one of each of body,
flows in any order; define distributionFormat as generic container for
either inline (embedded) or external distribution format of content,
such as SVG.
Resolution: Describe how to have style/timing rules that use predicates
and selectors that depend on structure and attributes of foreign
namespace vocabulary and still produce well-defined semantics in terms
of applying style/timing properties.
Resolution: Use camelCasing for attribute names and internal usage of
style parameters. For stylesheet languages, either embedded or
external, then require the user of some language to specify mapping as
required. Define recommended mapping for CSS and XSL in informative
annexes.
Resolution: add individual non-shorthand border properties.
Resolution: Add XSL glyph-orientation-* style properties to TT-AF spec.
*** WORKING ASSUMPTIONS ***
*** OPEN ACTION ITEMS ***
Action: [GA] To send notice to SMPTE, WAI, I18N, SYMM, SVG requesting
final comments on TT-AF-1-0-REQ by Nov 1.
Action: [DS] To send notice to MPEG, IETF, and 3GPP requesting
final comments on TT-AF-1-0-REQ by Nov 1.
Action: [MG] To send notice to Daisy requesting final comments on
TT-AF-1-0-REQ by Nov 1.
Action: [GF] Verify behavior of backspace commands with pop-on mode.
Action: [BB] To determine semantics of form-feed (FF) and report back.
To also check on HRC (0x0E) semantics.
Action: [GA] Request XML Schema WG revise definition of xs:Language to
use RFC3066.
Action: [SH] Will investigate use of media queries in this context and
report back.
Action: [DS with help of Paul Nelson and Peter Lofting] Write RFC to
register appropriate opentype/truetype font types as MIME media types,
suggest model of "application/font-<font-type-name>", e.g.,
"application/font-truetype".
Action: [GA] Discuss with XSL WG as required to resolve.
*** OPEN ISSUES ***
Issue: Whether to use XLink vocabulary, e.g., as used consistently by
SVG, or use "src" attribute as apparently will be done in XHTML2?
Issue: Whether to use IRIs instead of URIs? Note: XPointer and
Namespaces in 1.1 use IRIs?
Issue: Should we use "class" instead of "role"?
Issue: Need to define what semantics if 
 does come through (as
well as other NLF sequences).
Issue: If we need hierarchical definition of regions, e.g., due to
nested regions, then we should express this hierarchy separately from
flows hierarchy and reference regions from flows. Otherwise, if we have
a flat region model, i.e., regions all defined relative to origin of
display medium, then it would suffice to incorporate region definition
as style properties on each flow. We need to determine which of these
to support?
Issue: Whether to define the region and viewport vocabulary in content
section or in style vocab section?
Issue: Probably want to permit in logical content mode the selection of
content based on generic XML features of non-TT namespace descriptive
markup, e.g., for applying style and timing semantics, in which case an
appropriate TT container element shall be implied based on nearest
ancestor TT namespace element.
Issue: Need to think about cascading semantics; how to express, how to
apply, etc. Possibly use CSS semantics here as well.
Issue: for origin property, it appears to be somewhat unnatural to have
to express in terms of absolute left, right, top, bottom such that this
is portable for different writing modes; the intuitive definition is
that origin(10px,10px) is 10px down and right from container in LR-TB
writing modes, but that this is 10px down and left from container's top
right vertex in RL-TB writing modes, etc. In other words, is the
vertex for the reference point of the containing area and the vertex
for the reference point of the contained area always the TOP,LEFT
vertex or does this depend on the writing mode, e.g., TOP,RIGHT for
RL-TB and TOP,RIGHT for TB-RL?
*** URLs ***
[1] http://www.w3.org/International/iri-edit/draft-duerst-iri-02.txt
*** NEXT MEETING DATES ***
- January 7-8, 2004 Bangkok (JSRPD) or Tokyo (JSPRD or MSFT), or
UK (Soho; MSFT), or Cupertino (Apple)
- March 4-5, 2004 Mandelieur FR (W3C Tech Plenary)
- June 10-11, 2004 Boston (WGBH)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
END SUMMARY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Thierry MICHEL
W3C/ERCIM
Received on Tuesday, 9 March 2004 09:12:24 UTC