- 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 March 6-7, 2003, Cambridge, MA
DAY 1 (03/06/03)
Attendees
Glenn Adams (XFSI, Chair, Scribe) [GA]
Markus Gylling (Daisy) [MG]
Mark Hakkinen (JSRPD) [MH]
Dave Singer (Apple) [DS]
Thierry Michel (W3C) [TM]
Junsei Sato (Sharp) [JS]
Brad Botkin (WGBH/NCAM) [BB1] (Alternate for GF1)
Observers
Ivan Herman (W3C) [IH] (Observer)
Katie Haritos-Shea (CESSI, Accessible Solutions) (Observer)
Regrets
George Kerscher (Daisy) [GK]
Gerry Field (WGBH/NCAM, Invited Expert) [GF2]
Erik Hodge (RealNetworks) [EH]
Mike Dolan (invited expert) [MD]
Geoff Freed (WGBH/NCAM, Invited Expert) [GF1]
Absent
Patrick Schmitz (Ludicrum, Invited Expert) [PS]
************************************************************************
Approved Agenda
************************************************************************
Day 1 (Thursday, March 6, 2003)
0900 - 1030h Session 1
* Introductions
* Administrivia
* Requirements Document Planning
1030 - 1100h Break
1100 - 1300h Session 2
* Use Case Scenarios for TT Authoring
* General Authoring Exchange Format Requirements
1300 - 1400h Lunch
1400 - 1430h Joint Meeting with MMI WG
1430 - 1530h Session 3
* Basic Representation Requirements
* Lexical Syntax
* Character Sets and Encodings
1530 - 1600h Break
1600 - 1800h Session 4
* Semantic Markup Requirements
* Descriptive Markup
* Metadata Requirements
************************************************************************
Requirements Document Planning
************************************************************************
1. Purpose and Scope of Requirements Document?
Purpose: Refine details of what we are doing w.r.t. a TT technical
spec. Use this to drive auditing of our work as well as engender
buy-in from other groups.
[TM] WGs usually publish requirements as a working draft. Could be
published as a W3C Note; can be reviewable. Suggests not going through
full REC process; would consume much energy; focus on tech spec.
Suggests going as a WD and then publish as Note if desired. There is
presently no commitment for or against adding features.
Scope: Question had been Authoring (Exchange) Format (AF) versus
Distribution (Exchange) Format (DF); had concluded that we would focus
on AF rather than DF.
[GA] Notes that in some contexts (e.g., TV transmission), that a DF
would have minimum utility, at least in radiodiffusion context, since
well established standards already exist; on other hand, a DF format to
be used with http/rtp delivery to a SMIL player may have utility.
TTWG has previously decided on focusing on AF.
[GA] AF should define core features and some extension mechanism that
permits supporting features in some DFs that are not directly supported
by AF core feature set.
[GA] One way is to focus on defining specific element vocabulary, e.g.,
as done in XML DSIG, using XSD, and then let industry, external, or
even other W3C specs (perhaps some we write) to create profiles of use
of specific elements. Thinks it is important to separate definition of
TT elements and definition of combinations of use of those elements.
This process can occur as we make progress in defining solution spec.
[TM] Will need to at some point to define exit criteria in terms of
implementations et al.
[DS] To what extent do we define presentation behavior?
[BB1] Will have specific ideas of presentation semantics for some
features and will need to capture.
2. Who are editors?
[GA] has volunteered.
[BB1] Volunteers Geoff to help. Brad may help as well.
[TM] If we go for modularization, then, using SMIL process, would best
have different editors for different modules.
[GA] I'm focusing on the requirements document here as opposed to our
modular techncial spec.
3. Document format (for Req doc)? xmlspec?
[GA] Describes usage of xmlspec.
[TM] Agrees that this should be adopted. Will help meet QA guidelines.
[GA] XMLSpec: http://www.w3.org/XML/1998/06/xmlspec-report-v21
[IH] A team member has put together doc for helping editors:
http://www.w3.org/2003/Editors.
[GA] Suggests adding info on useful XSLT stylesheets for transforming
XMLSpec content.
Action: [GA] Send email to author of editors home page.
Resolve: Use xmlspec for all TT WG document deliverables.
Agreed.
[DS] Will we use XSD or DTD for normative definitions?
[GA] Suggests XSD.
[MG] Notes that SSML uses XSD as normative and DTD as informative.
[MH] Notes that XmlSpy can transform either way.
[TM] Proposes we adopt XSD as normative.
Resolve: Will use XSD for normative definition of vocabularies et al.
4. Review and LC process?
[GA] Had asked [TM]; answer: no formal process in place for how to
handle Requirements documents. QA WG also doesn't have guidelines on
this (yet).
Resolve: Will publish REQ doc as a WD, solicit review, then later
consider to publish as Note.
[TM] Need to consider current charter's milestone schedule.
[GA] Feels interim milestones are fluid as long as we reach overall
closure on REC in allotted time.
[TM] How much time to assign to produce REQ document?
[DS] Hard to do until we have firm idea of what we are doing. Inputs
from BBC and Daisy are raising interesting issues. Less confident about
timetable.
Requirements Document Schedule
Apr 15 - Working Draft for Public Review
May 27 - Proposed Working Draft
Jun 31 - TTWG Approved Working Draft - Could go to Note at this point
[DS] Do we need another F2F for finalizing REQ doc?
Candidates for Next Meeting Schedule
Mar 24-26 IUC, Prague
May 12-15 Daisy Conference, Amsterdam
May 19-20 AC Meeting, Budapest
May 21-23 WWW2003, Budapest
May 24 Developers Day, Budapest; SVG/WAI presentations/tracks
Tentative Next Meeting Dates
Jun 10-11 TTWG F2F in UK (BBC) - Confirmed
Sep 11-12 TTWG F2F in Japan or Bangkok (Host T.B.D.)
5. Title?
[IH] Thinks timed text may be a misnomer. Has an idea that
XHTML + SMIL timing is "timed text".
[IH] May want to consider renaming work depending on what comes out
of the process.
[GA] Suggest some caution about going too far with semantic markup.
[BB1] May say that a video description takes advantage of the timed
text mechanism.
[DS] Would speaker ids (roles) apply to audio as well as text?
[GA] Propose that we use "Timed Text (TT) Infoset 1.0 Requirements"
as a working title to be refined/changed as necessary.
No objection.
************************************************************************
Use Case Scenarios for TT Authoring
************************************************************************
[MG] Simple scenario for audio+text. Already implemented by Daisy for
SMIL 1.0. Customized players. Download SMIL + audio + XML based text.
[GA] Asks how text is represented.
[MG] Uses <text> element with URI referencing fragment in text file.
[GA] What format for fragment identifier? xpointer? xpath?
[MH] Only uses identified element (ID) referencing.
[GA] Interesting question regarding how rich text structures we want to
be able to support with timing; are we talking about timing all of
XHTML textual structures (e.g., tables, lists) or we talking only about
simple text structures such as inline phrasal structures.
[GA] What are the semantics of "timing" complex XHTML structures like
tables, etc.? Does this equate to animating visiblility property
(visible/hidden) or display property (auto/none)?
[GA] Hasn't seen study performed on timing of complicated XHTML
elements.
[MH] Had a requirement to separate timing form textual based content,
e.g., copyright restrictions.
[DS] Need to resolve architectural model; otherwise will be
floundering. key-frame only, key-frame and difference markup,
incremental update, i.e., (1) entire document; (2) start with document,
then deltas; (3) is special version of (2). [(3) requires carouseling
of some structure to support random stream access.]
[GA] Our decision to focus on AF drives us towards (1) "entire
document" mode. This may or may not have event/indefinite timing
semantics, but will definitely have definite timing semantics.
[MH] Shows slide with basic Daisy Application structure consisting of:
(1) NCC (navigation control center), called NCX in Daisy 3; typically
points at <par> in (2) SMIL file element, which points to (3) text file
element and (4) audio file. Text file format is XHTML or DTDBook3.
"Activating" an element in the text file causes it to be highlighted
and/or scrolled to depending on player; may take content and send to
simpler device (e.g., braille).
[DS] Describes 3GPP development requirements for timed text as
intentionally high level but narrow, download only but not streaming,
binary only but no XML. Could define as streaming, but work wasn't done
by 3GPP to define.
[GA] Shows film, digital cinema, and DVD caption/subtitle delivery and
presentation scenarios.
[BB1] Authoring for D-Cinema is essentialy identical for Television and
most multimedia production.
[BB1] Describes CC process for television. EIA-608: 15 row x 32 column
raster, fills and flips two buffers (fill and swap), some caption
styles that don't use double buffers: roll up style (like news -- adds
text), paint on style; pop on/up uses double buffer. Paint on uses
display; can see display update; pop on is done in backing store and
then flipped with active display buffer.
[GA] Creates example to probe word level versus caption level timing.
<caption captionBegin="0.2s" captionEnd="indefinite">
<word audioBegin="0.1s" audioEnd="0.2s">the</word>
<word audioBegin="0.3s">quick</word>
<word audioBegin="0.5s">brown</word>
...
</caption>
[BB1] Useful concept.
[GA] Are there any general AF requirements?
[BB1] Probably do not want to support every esoteric feature in 708.
However, need some extension mechanism for these features.
General Requirements
(1) extensibility mechanism that permits the inclusion of metadata or
semantic markup/structure that was not previously defined in the core
standard;
(2) conditional content inclusion/selection
[BB1] How about conditional content support? i.e., switch?
[GA] Good question. Don't know answer. Any requirements for
fine-granularity conditionality of content with timed text?
[BB1] One possibility is switching between (natural) language subtitles.
[BB1] May use to support full transcribed captioning (including
non-voice audio, e.g.); may want to have conditionalization in timed
text that supports this;
[GA] Example:
<caption>Help!</caption>
<switch customTest="full-audio-description">
<caption>[gun fires]</caption>
<caption>[glass breaking]</caption>
</switch>
[BB1] Need to describe adequately what "this stream" does, e.g., this
caption stream.
[GA] Sounds like you want to say we need sufficient metadata to
describe content.
[DS] Wants to discuss how predicable is a visual presentation if that
is what is expected to be presented. For example, script/font handling.
[GA] Sounds like you want to ask whether rendition integrity is a
requirement.
************************************************************************
Text Functional Category
************************************************************************
1. format - [GA] proposes plain text plus markup, with XML overall
markup format
Resolution: Agreed
[BB1] notes that QT is really "plain text plus markup"
[GA] should we go with XML 1.1 or XML 1.0?
Action: [GA] discuss with XML CG...
2. character set - unicode 3.X (or 4.0)
[BB1] suggests adding a metadata element to indicate which unicode
version repertoire applies;
[GA] would need to define a default version in case none were indicated;
[MG] are we excluding other character sets?
[GA] no
[MG] maybe we don't need to say much about character sets; i.e., simply
inherit XML's use of Unicode;
Tentative Resolution: simply adopt XML 1.? character set / encoding
requirements; i.e., don't specify any additional requirements that
impact conformance;
3. named character entities - already get xml set (lt, gt, amp), do we
want xhtml set(s)?
Resolution: if we do support a set beyond XML, then we will adopt one
already defined and not invent one.
[MG] whether to support xhtml set depends on what we use from xhtml.
Open Issue: whether to support xhtml entity sets?
4. numeric character entity - inherited from XML
no resolution required - no issue
5. text wrap controls - inherit from XML; both normalization and
xml:preserve
no resolution required - no issue
[DS] is soft wrap required?
[GA] what you want to ask is whether line breaking (line layout) is
required to be supported or not by a user agent
[GA] consider line breaking support under style category, will be
impacted according to whether we support XHTML/CSS presentation
semantics
6. bidi control characters - from AF perspective, should be allowed,
but may want to have recommendation against their use if we make use of
XHTML such that the "dir" attribute is present (in which case we might
want to recommend they not be used and that "dir" be used instead)
Resolution: should address possible redundancy between Unicode Bidi
Controls and markup in the case that appropriate markup is employed;
see http://www.w3.org/TR/unicode-xml/#Bidi.
Agreed.
********
[GA] Notes that we are starting to agree to REQs that essentially are
in the solution space, and are not general; e.g., shall use XML,
Unicode, etc. Have no problem with this approach, but some may feel
this is less than general.
[*] No objection to this approach. May want to note in REQ doc those
places where a (entire or partial) solution is being required rather
than abstract functional requirement.
7. minimum glyph support - this is a style/presentation/user agent
issue; probably outside scope for AF; may want to require mechanism to
permit author (system) to indicate in metadata whether specific script
rendering/font support is required.
Agreed.
8. preserve white space - inherit XML xml:preserve semantics, need to
call out usage
Agreed.
9. language - inherit XML xml:lang semantics, need to call out usage,
and define what language
[BB1] Useful metadata.
Agreed.
********
Semantic/Descriptive Markup Requirements
********
Open Issue: Should we support both intrinsic and extrinsic text?
[DS] Consider external specs for metadata/semantic markup.
[GA] May want to look at TEI.
********
Options for Specification Structure
********
Separate Modules (=specs/docs) for
(0) tt framework
(1) tt core vocabulary
(2) tt core document type(s)
(3x) tt extension vocabulary sets #i...#j
(4x) tt extension document types #m...#n
********
Markup Requirements
********
1. do we want to adopt some or all xhtml vocabulary in our core
vocabulary? [a sub-question is whether we support them in XHTML NS or
import them into TT NS?]
[GA] probably some, not sure about all
2. if so, then what xhtml vocabulary?
e.g., div, p, span?
e.g., b, i, tt?
e.g., strong, em, code?
[GA] at least div, p, span, img, not sure about others.
div = fo:flow
p = fo:block
span = fo:inline
img = fo:external-graphic
[DS] why are we talking about img?
[GA] because not all glyphs have character representations in Unicode,
e.g., [CC], e.g., egyptian heiroglyphs, gaiji, etc... describes
potential use of <svg:glyph> and <svg:altGlyph> usage.
[BB1] notes that support for images may facilitate sup-picture
representations for existing DVD and D-Cinema uses.
[MG] Not sure why <p> is needed. Concerned about <p> being used to
specify parts of paragraphs, e.g., a line.
[GA] Perhaps <tt:blk>, <tt:inl>, <tt:img>. Where <tt:blk> can have blk,
inl, and img children, inl can have #PCDATA children, and img has no
content children.
3. if not, do we want to specify reqs for some specific functional
markup without drawing from any specific solution space?
[GA] probably
4. what higher level structural markup that is clearly not in xhtml
needs to be required?
Resolution: TT document type(s) need not be XHTML Host Language
Conformant.
Agree.
Resolution: TT document type(s) need not be XHTML Integration Set
Conformant.
Agree.
Working Assumption: not requiring single namespace; not requiring
multiple namespaces; i.e., leaving open possibility for single
namespace docs while admitting potential for multiple namespace docs.
************************************************************************
Adjourn for Day
************************************************************************
DAY 2 (03/07/03)
Attendees
Glenn Adams (XFSI, Chair) [GA]
Markus Gylling (Daisy) [MG]
Mark Hakkinen (JSRPD) [MH]
Dave Singer (Apple) [DS]
Thierry Michel (W3C) [TM]
Junsei Sato (Sharp) [JS]
Brad Botkin (WGBH/NCAM) [BB1] (Alternate for GF1)
Observers
Bert Bos [BB2] (W3C) (Observer)
Michel Suignard (MSFT) (Observer)
Richard Ishida (W3C) (Observer)
Regrets
George Kerscher (Daisy) [GK]
Gerry Field (WGBH/NCAM, Invited Expert) [GF2]
Erik Hodge (RealNetworks) [EH]
Mike Dolan (invited expert) [MD]
Geoff Freed (WGBH/NCAM, Invited Expert) [GF1]
Absent
Patrick Schmitz (Ludicrum, Invited Expert) [PS]
************************************************************************
Approved Agenda
************************************************************************
Day 2 (Friday, March 7, 2003)
0900 - 0930h Joint Meeting with SVG WG
0930 - 1030h Session 1
* Stylistic Feature Requirements
* Stylistic Information Representation
1030 - 1100h Break
1100 - 1300h Session 2
* Timing Feature Requirements
* Timing Information Representations
1300 - 1400h Lunch
1400 - 1430h Demos
1430 - 1530h Session 3
* Animation Feature Requirements
* Animation Feature Representations
1530 - 1600h Break
1600 - 1800h Session 4
* Technical Specification Document Planning
* Wrap-Up
************************************************************************
Joint Meeting with SVG WG
************************************************************************
Action: [GA] to inform Chris Lilley of location of comparison
document so that he can fill in an "SVG" column.
************************************************************************
Style Feature Requirements
************************************************************************
General Issues
1. whether to support inline styling via attribution?
Ex. <tt:block text-indent="10pt"/> <!-- ala XSL-FO, SVG -->
Pro: it facilitates XSLT transforms as it works entirely in XML domain
Pro: very simple, maps easily to delivery formats, e.g., QT, RT, etc.
Con: it encourages mixing presentation information with content,
which may be problematic regarding DI and WAI usages; [on other hand,
from AF perspective, it may not be a problem because a transformation
is implied to some DF.]
Con: means changes to vocabulary space (at least attribute
vocabulary) in order to introduce new or changed styles;
2. whether to support inline styling via style attribute?
Ex. <tt:block style="text-indent:10pt">
Pro: very simple, maps easily to delivery formats, e.g., QT, RT, etc.
Pro: allows introducing new/changed styles without changing attribute
vocabulary
Con: may require transform as well to DF if not same style
language/mechanism
Con: requires defaulting or scoping rules for assigning style
language type to style attribute.
Con: mixes presentation and content
3. whether to support inline styling via embedded style sheet?
Ex. <tt:style type="text/css">tt|block { text-indent: 10pt}</tt:style>
Pro: does better job of separating presentation and content, but
still not perfect
Con: requires parsing/transform from embedded style language, if
different from DF
4. whether to support external styling via style sheet?
Ex. <?xml-stylesheet href="foo.css" type="text/css" media="screen"?>
Ex. <tt:external-resource role="stylesheet" xlink:href="foo.css"
type="text/css"/>
Pro: complete separation of presentation and content (providing that
content did not intrinsically specify presentation semantics)
Pro: may support multiple expressions of style information in different
languages that facilitate mappings to multiple DFs based on distinct
styling usage
Con: complicates streaming; requires keeping files together/associated,
etc.
*******
[GA] Propose supporting both inline (immediate) mode styling and
out-of-line (indirect) mode styling. Prefers attribution approach over
style attribute approach for immediate inline styling; i.e., #1 instead
of #2. Feels #1 is better because it (1) allows for XSLT mapping more
directly without having to understand value space syntax for "style"
attribute; also allows schema validation of style attributes.
[GA] Proposes defining TT vocabulary to accommodate both #3 and #4
cases; however, for AF context, #3 may not be needed in a AF document
type; however, #3 probably will be desired in a DF document type.
[BB2] Authoring guidelines should make it clear that use of #1/#2 makes
it complex or impossible for reuse in various contexts.
Tentative Resolution: support all of #1 through #4 in core vocabulary;
specify document types that vary along simplicity scale for direct
authoring, e.g., one doctype that permits inline styles, another forces
separation of style/content, etc.
Agreed.
5. whether to support user agent styling?
yes, of course; support via #3/#4 above;
Resolution: Require UAAG Checkpoint 4.14.
Agreed.
6. which style languages? CSS, XSL-FO?
[BB1] Should be able to use AF as DF in simple multimedia case.
[GA] In other words, we shouldn't do anything to preclude this use
case. However, for many existing distribution channels, it is pretty
clear that legacy formats will continue to be used, e.g., EIA-608/708.
[DS] Should not invent new styling language.
Resolution: Shall not invent new styling language.
Agreed. But may produce other mid/high level constructs that map to
styling language.
[BB2] Not necessary to use same vocabulary as CSS or XSL-FO; may
define higher level constructs that map to CSS, etc.
Resolution: To the extent that we define attribute vocabulary for style
properties, then names and value syntax of attributes shall be
according to the following (in priority order in case of conflict):
(1) CSS2
(2) XSL FO
(3) SVG
(4) SMIL
(5) CSS3
This is a working guideline, subject to reopening if required to
resolve specific cases of differences.
Agreed.
[BB2] If a difference is found, please notify affected groups.
[BB2] Notes that TAG issued finding on property naming consistency
between W3C specs; see
http://www.w3.org/2001/tag/doc/formatting-properties.
7. Should we support presentation markup elements in element
vocabulary? e.g., <b>, <i>, etc.?
Ex: <tt:b> vs <tt:inline font-weight="bold">bold text</tt:inline>
<tt:i> vs <tt:inline font-style="italic">italic</tt:inline>
[BB2] In this case, <tt:b>, <tt:i> are essentially shorthand notations,
whereby certain presentation styles are assumed.
Resolution: If we do define presentation oriented markup elements, then
shall do so by defining them as shorthands for explicit fully specified
forms, e.g., define <tt:b> to be equivalent to <tt:inline
font-weight="bold">.
Agreed.
[BB2]/[GA]: prefers not to define, but would not object.
Action: Persons that wish to champion specific presentation markup
elements should make proposal.
Tentative Core Style Property List
From CSS2:
* font-family
* font-style
* font-weight
* font-size
* text-decoration
* text-shadow
* text-align
* vertical-align
* color
* background-color
* position
* top
* left
* bottom
* right
* width
* height
* z-index
From XSL-FO:
* display-align
From SVG:
* opacity
* rgba() function value for color, background-color
Tentative Non-Core Style Property List (from CSS2 vocabulary)
From CSS2:
* font-stretch
Questions
1. Is hilite different from background? Do we want to define any
specific vocabulary (either elements or attributes) to designate
highlighting? Highlighting can be handled by, e.g., <tt:inline
class="hilite">...
[DS] Leave this as open issue; will probably fall out of other
decisions.
Open Issue: How to handle highlighting?
2. What is use case for vertical-align? CSS2 is somewhat overloaded.
Action: To be addressed by [BB1]/[GF1] in their study of style props.
Resolution: For all core style properties, define corresponding
attribute vocabulary.
Agreed.
Action: [BB1] and [GF1] to analyze the above tentative style properties
to determine if they support the style features indicated by [GF1]'s
proposed style document.
[GA] Crafts example that would support scenario described by [BB1]
where one has a left text-justified block which itself is right
justified in block flow:
<!ENTITY nl "<tt:br/>">
<tt:block>
<tt:inline>
<tt:inline-container>
<tt:block width="30%"/>
<tt:block width="70%" text-align="left">
Some text with some&nl;
Hard line breaks.
</tt:block>
</tt:inline-container>
</tt:inline>
</tt:block>
3. May need to look at CSS3 Text Module to determine if we want any
advanced typographic properties.
Open Action: Await champion to investigate.
[MS] Need to look at writing-mode and unicode-bidi properties. Look at
SVG to see what they did.
************************************************************************
Timing Requirements
************************************************************************
Questions
1. What are implied timing sequence and parallel semantics? e.g., do we
assume that all samples are essentially an implied sequence, or do we
permit parallelism, or are we generally unconstrained, and require
explicit par/seq information?
[GA] Simple case is one single implied sequence. More general case
might allow formatting to target text to separate regions/boxes and
thus permit parallelism. Do we want to support only simple case or not?
If not, then what level of parallelism?
[MS] Parallelism may apply for ruby.
[BB1] Multiple languages may appear in parallel.
Tentative Core Timing Attribute List
* begin
* end
* dur
Resolution: Adopt basic SMIL timing attributes (begin, end, dur) as
well as descriptive language regarding implicit, explicit, desired,
effective, definite times and durations. Not including value spaces in
this resolution.
Agreed.
Question: do we want time containment vocabulary (i.e., seq, par)?
[GA] incongruities may exist between timing and layout containment
and sibling relationships; if you merge, then you have to flatten out
either timing or layout descriptions in order to support incongruities;
this results in a loss of generality when one structure is flattened.
Example of Incongruity:
<ol timeContainer="par">
<li begin="9s" dur="indefinite">Gold</li>
<li begin="5s" dur="4s">Silver</li>
<li begin="0s" dur="5s">Bronze</li>
</ol>
<tt:seq>
<tt:inline begin="0s" region="r3">Bronze</tt:inline>
<tt:inline begin="5s" region="r2">Silver</tt:inline>
<tt:inline begin="9s" region="r1">Gold</tt:inline>
<tt:seq>
Example of Parallelism:
<smil>
...
<body>
<par>
<!-- <video src="..." syncMaster="yes"> -->
<textstream src="..." syncBehavior="locked">
</par>
</body>
</smil>
<tt:style>
.r1 { position: absolute; top: 10px; left: 20px }
.r2 { position: absolute; top: 50px; left: 50px }
</tt:style>
<tt:tt>
<tt:block class="r1" begin="marker(smpte=10:00:00:00.0)" dur="5s">
First Scene - First Caption</tt:block>
<tt:par dur="5s">
<tt:block class="r1" dur="1s">
Second Scene - First Caption</tt:block>
<tt:block class="r2" begin="0.5s" dur="2s">
Second Scene - Second Caption</tt:block>
</tt:par>
</tt:tt>
Options:
1. define containment element vocabulary in core vocab set, and then
differentiate between different document types; one could employ no
containment elements, another could specify containment.
2. require flattened timing models at loss of generality of expression,
but increase in processing simplicity. note that for AF, processing
simplicitly is not a strict requirement.
Question: Do we need excl/priorityClass elements? Need to figure out
use cases.
[BB1]/[GA] Do walk through of possible usage; [GA] thinks it is
handled by SMIL event based timing or DOM invocation with indefinite
timing.
<seq>
<ref id="m1" dur="indefinite"/>
<ref id="m2" begin="m1.end"/>
</seq>
Resolution: every core vocabulary element must be used in at least one
core document type; conversely, if a vocabulary element is not used in
any core document type, then it shall not be in core vocabulary.
Agreed.
Resolution: support seq/par in core element set; may need to be moved
to extension element vocab if we don't define any use in a core
document type.
Agreed.
[DS]/[GA] Simplest document type probably won't have seq or par, but
only flattened with implicit seq.
Question: What timing attribute value semantics to support?
Possibilities from SMIL 2.0 include:
* offset-value YES
* syncbase-value NOT APPLICABLE; REQUIRES REF TO OTHER MEDIA
OBJECT
* event-value YES (may need to put in extension vocabulary)
* repeat-value [BB1] WILL INVESTIGATE
* accesskey-value YES
* media-marker-value YES, define SMPTE markers; also need to remove
req
for id-value
Ex: begin="marker(smpte=10:00:00:00.1)"
Issues: (1) need to remove requirement for id-value in marker syntax
(2) need to define smpte-30-non-drop (others?)
(3) need to define meaning in absence of external association
with some marker master media;
* wallclock-value YES
* indefinite TENTATIVE NO, BUT LOOK FOR USE CASES
Issues: (1) would we support scripting in TT context? if not, then
beginElement() is not applicable;
(2) would we support hyperlink targeting of TT content
elements such that indefinite would be useful for
starting element? if not, then don't need;
Question: Do we want to support list of values or just single value,
cf. begin-value-list and end-value-list in SMIL 2.0 Timing.
Resolution: Specify single value for core vocab, permit champion for
multiple values in extension vocabulary.
Agreed.
************************************************************************
Animation Feature Requirements
************************************************************************
Types of animation:
* scrolling
* hiliting
* blinking
Proposal: Map scrolling to <svg:animateMotion>.
Action: Need Proposal for scroll (motion) animation markup; [DS] will
investigate.
Proposal: Map hiliting to <svg:set attributeName="background-color">.
Ex 1:
<tt:hilite xlink:href="someOtherElement begin="0s" dur="5s"
class="styleForHilite"/>
Ex 2:
<tt:inline id="w1">Word1</tt:inline>
<tt:inline id="w2">Word2</tt:inline>
In Animation Sheet (posit), have:
<tt:seq>
<svg:set xlink:href="#w1" attributeName="background-color"
to="yellow"
dur="5s"/>
<svg:set xlink:href="#w2" attributeName="background-color"
to="yellow"
dur="5s"/>
</tt:seq>
[BB1] Does set require unset value?
[GA] thinks so but not certain.
Action: Need Proposal for hilite animation markup; [MH] will
investigate.
Proposal: Map blinking to <svg:set attributeName="visibility">.
[DS] blinking is abhorrent. [MH] agrees.
Resolve: Ignore blinking. Champion can propose for extension vocab if
desired.
************************************************************************
Tech Spec Doc Planning
************************************************************************
********
Options for Specification Structure
********
[GA] Proposes as starting point:
Separate Modules (=specs/docs) for
(0) tt framework
(1) tt core vocabulary
(2) tt core document type(s)
(3x) tt extension vocabulary sets #i...#j
(4x) tt extension document types #m...#n
Tentative Resolution: Go with above approach. Document approach in REQ
document.
Agreed.
********
Miscellaneous
********
[MH] How to transition docs to public list?
[GA] Currently working on revising the groups home page and member only
page.
[GA] Notes that charter indicates both minutes and members list will be
public.
[DS] Asks about email of members?
[GA] Suggests not specifying in public list.
Resolution: Wait until docs are sensible and consistent to post for
public discussion. Need not be complete however.
Agreed.
Resolution: [MG] will be FAQ doc editor; doesn't mean he will write all
entries, but, rather, will own doc and dispatch to members to answer,
etc.
Agreed.
Resolution: [DS] to work with [GA] on resource list.
************************************************************************
Adjourn
************************************************************************
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
START SUMMARY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*** TENTATIVE RESOLUTIONS ***
TR-1: Simply adopt XML 1.? character set / encoding requirements; i.e.,
don't specify any additional requirements that impact conformance.
TR-2: Support all of (1) inline styling via attribution, (2) inline
styling via "style" attribute, (3) embedded stylesheet, and (4)
external stylesheet in core vocabulary; specify document types that
vary along simplicity scale for direct authoring, e.g., one doctype
that permits inline styles, another forces separation of style/content,
etc.
TR-3: Adopt technical specification structure with following modules:
(0) tt framework (1) tt core vocabulary (2) tt core document type(s)
(3x) tt extension vocabulary sets #i...#j (4x) tt extension document
types #m...#n; document approach in REQ document.
*** RESOLUTIONS ***
R-1: Use xmlspec [1] for all TT WG document deliverables.
R-2: Will use XSD (XML Schema) for normative definition of vocabularies
and document types.
R-3: Will publish REQ doc as a WD, solicit review, then later consider
to publish as Note.
R-4: Adopt plain text plus markup with XML overall markup format.
R-5: If we do support a set beyond XML, then we will adopt one already
defined and not invent one.
R-6: Address possible redundancy between Unicode Bidi Controls and
markup in the case that appropriate markup is employed; see
http://www.w3.org/TR/unicode-xml/#Bidi.
R-7: TT document type(s) need not be XHTML Host Language Conformant.
R-8: TT document type(s) need not be XHTML Integration Set Conformant.
R-9: Require UAAG Checkpoint 4.14.
R-10: Shall not invent new styling language, but may produce other
mid/high level constructs that map to styling language.
R-11: To the extent that we define attribute vocabulary for style
properties, then names and value syntax of attributes shall be
according to the following (in priority order in case of conflict): (1)
CSS2 (2) XSL FO (3) SVG (4) SMIL (5) CSS3. This is a working guideline,
subject to reopening if required to resolve specific cases of
differences.
R-12: If we do define presentation oriented markup elements, then shall
do so by defining them as shorthands for explicit fully specified
forms, e.g., define <tt:b> to be equivalent to <tt:inline
font-weight="bold">.
R-13: For all core style properties, define corresponding attribute
vocabulary.
R-14: Adopt basic SMIL timing attributes (begin, end, dur) as well as
descriptive language regarding implicit, explicit, desired, effective,
definite times and durations. This resolution does not including value
spaces for these attributes.
R-15: Every core vocabulary element must be used in at least one core
document type; conversely, if a vocabulary element is not used in any
core document type, then it shall not be in core vocabulary.
R-16: Support seq/par in core element set; may need to be moved to
extension element vocab if we don't define any use in a core document
type.
R-17: Support following begin/end values: (1) offset-value, (2)
event-value, (3) accesskey-value, (4) media-marker-value (with
modification), and (5) wallclock-value.
R-18: Support single begin/end value in core vocabulary; remain open to
someone championing multiple values in extended vocabulary.
R-19: Don't support blinking animation; champion can propose for
extension vocab if desired.
R-20: Wait until docs are sensible and consistent to post for public
discussion. Need not be complete however.
R-21: [MG] will be FAQ doc editor; doesn't mean he will write all
entries, but, rather, will own doc and dispatch to members to answer,
etc.
*** WORKING ASSUMPTIONS ***
WA-1: Don't require single namespace. Don't require multiple
namespaces; i.e., leave open possibility for single namespace docs
while admitting potential for multiple namespace docs.
*** OPEN ACTION ITEMS ***
A-1: [GA] to send email to author of editors home page to suggest
adding list of available XSLT transforms for xmlspec.
A-2: [GA] to discuss possible use of XML 1.1 with XML CG.
A-3: [GA] to inform Chris Lilley of location of comparison
document so that he can fill in an "SVG" column.
A-4: [*] Champion specific presentation markup elements as
desired.
A-5: [BB1]/[GF1] to analyze the above "Tentative Core Style Property
List" to determine if they support the style features indicated by
[GF1]'s proposed style document.
A-6: [BB1]/[BF1] to consider use of vertical-align in their study of
style props.
A-7: [*] Consider need for CSS3 text module features.
A-8: [DS] to propose scroll (motion) animation markup.
A-9: [MH] to propose hilite animation markup.
A-10: [DS] to work with [GA] on resource list.
*** OPEN ISSUES ***
I-1: Whether to support conditional constructions (e.g., switch)?
I-2: Whether to support xhtml entity sets?
I-3: Whether to support non-flowed text, flowed text, or both?
I-4: Should we support both intrinsic and extrinsic text? i.e.,
text internal and/or external to TT document(s)?
I-5: How to handle highlighting? [N.B. See A-9]
I-6: Whether to support writing-mode and unicode-bidi?
I-7: Whether to support excl/priorityClass?
*** URLs ***
[1] http://www.w3.org/XML/1998/06/xmlspec-report-v21 (XMLSpec)
[2] http://www.w3.org/2003/Editors (Editors Home Page)
[3] http://www.w3.org/TR/unicode-xml/#Bidi (BIDI Usage)
[4] http://www.w3.org/2001/tag/doc/formatting-properties (Properties)
*** NEXT MEETING DATES ***
Jun 10-11, 2003, UK (BBC R&D, Kingswood Warren), Confirmed
Sep 11-12, 2003, Tokyo or Bangkok, Host T.B.D.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
END SUMMARY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Thierry MICHEL
W3C/ERCIM
Received on Tuesday, 9 March 2004 09:12:22 UTC