W3C home > Mailing lists > Public > public-tt@w3.org > August 2004

Minutes of TT WG Meeting on June 22-24, 2004, Mt. View (MSFT)

From: Thierry MICHEL <tmichel@w3.org>
Date: Fri, 27 Aug 2004 16:20:18 +0200
To: <public-tt@w3.org>
Message-ID: <000601c48c40$fcc82ff0$0300000a@wistiti>


Minutes of TT WG Meeting on June 22-24, 2004, Mt. View (MSFT)

Attendees

  Glenn Adams (XFSI, Chair, Scribe) [GA]
  Dick Bulterman (CWI) [DB]
  Mike Dolan (Invited Expert) - Thu (Phone)
  Geoff Freed (WGBH/NCAM) [GF]
  Sean Hayes (MSFT) [SH]
  Erik Hodge (REAL) [EH] - Tue/Wed (Phone)
  Dave Kirby (BBC) [DK] - Thu (Phone)
  Thierry Michel (W3C) [TM]
  Dave Singer (Apple) [DS]

************************************************************************
Agenda
************************************************************************

Day 1 (Tuesday, June 22, 2004)

  09:00 - 10:30 Agenda Planning
                Review and Acceptance of Prior Minutes
  10:30 - 11:00 Break
  11:00 - 12:30 Content Selection Support/Usage
                Review XPath subset proposal [SH]
		Hyperlinking Support/Usage
  12:30 - 13:30 Lunch
  13:30 - 15:00 Timing Schema Module and Example Review
  15:30 - 16:00 Break
  16:00 - 17:30 Timing Schema Module and Example Review

Day 2 (Wednesday, June 23, 2004)

  09:00 - 10:30 Styling Schema Module and Example Review
  10:30 - 11:00 Break
  11:00 - 12:30 Styling Schema Module and Example Review
  12:30 - 13:30 Lunch
  13:30 - 15:00 Decision on LF Only or LF/PF or LF/PF/NF
  15:30 - 16:00 Break
  16:00 - 17:30 Metadata Module Finalization

Day 3 (Thursday, June 24, 2004)

  09:00 - 10:30 DFXP Feature Review
  10:30 - 11:00 Break
  11:00 - 12:30 Issues Tracking System
  12:30 - 13:30 Lunch
  13:30 - 15:00 Review TT-AF-1-0 Spec Text
  15:30 - 16:00 Break
  16:00 - 17:30 Action Item Review

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Day 1 (Tuesday, June 22, 2004)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Agenda Planning
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Above agenda accepted.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Review and Acceptance of Prior Minutes
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Not discussed.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Content Selection Support/Usage
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[GA] reviews current styling/timing module usage.

[SH] may need to restrict precept="matchevery" in timing module;

[GA] issue is whether or not to permit multiple timesheets to be
active at one time; is this or can this be well-defined? if not,
then reject; if so, is there use case and is complexity justified?

[GA] it may be possible to be well defined in the limited case
of specifying begin/end times, so that these would effectively
map to multiple begin/end times on one timesheet; however, for
other attributes, e.g., dur, repeat, etc., it is probably not
well defined on the surface, and would need conflict resolution
rules;

[SH] possible use cases: multiple timesheets active, but having
separate rendering (i.e., in separate apps/processes -- unaware
of each other); thinks there may be conflicts with competing
expressions;

Tentative Resolution: given that it would require considerable
research to determine if and how multiple active timesheets are
well defined, given lack of use case scenarios, given expected
complexity of implementation, conclude that multiple concurrent
timesheet support not be provided in TT-AF-1-0; may be reopened
if someone conducts research to provide definition of semantics
of concurrent timesheets and shows that expected complexity is
justified by fulfilling real use cases.

Corollary Resolution: similarly, do not support multiple non-
concurrent timesheets, due to lack of use cases and expected
implementation complexity.

Action: [GA] ensure that head module excludes multiple
timesheets, i.e., at most one timesheet may be selected on a
temporally static basis.

+ granularity? everywhere or limited? possible limited: styling,
  rule, timing, par/seq/excl/cue, div/p/span/a/{other embeds?}

Tentative Resolution: Permit content selection at the following
levels of granularity:

* head    - styling+
* head    - timing
* styling - rule+
* timing  - (seq|par|excl|cue)+
* content - (div|p|span|a|image|use)+

Action: [GA] ensure that styling module provides for selection
of a lexical sequence of rules as opposed to an individual rule.

Action: [GA] ensure that timing module provides for selection
of a lexcial sequence of (seq|par|excl|cue) as opposed to an
individual timing container or cue element.

Action: [GA] ensure that head module admits only one timing
element.

Open Issues: Whether or not to support selection of following:
metadata.

Tentative Resolution: do not support selection directly on
metadata; note that for content or other elements that can contain
metadata as children, then that content or other elements may be
selectable.

[GA] Briefly reviewed current embed schema module which defines
audio, font, and image elements. Notes that at present audio
element not used in content model except for defs element inside
head. Wonders how to incorporate audio into content model.
Wonders whether to permit use of image elt in defs or just inline
in content.

[*] discussion ensued about embeds and referencing of embeds.

[GA] suggests we may want to support use of "use" elt (a la
mode de SVG) in order to reference image elt in head elt.

[SH] do we need to define equipment to handle TTS (text to speech)
in TT-AF-1-0?

[GA] Daisy people would say yes.

[SH] When Daisy folks show up at meeting, we can discuss.

Action: [GA] Contact Daisy absentees of TTWG to see if they want
to promote this. Need them to attend.

Action: [GA] ensure that head schema module supports defs elt
with audio|image|font children.

Tentative Resolution: introduce "use" elt to instantiate image
defined in /tt/head/defs as well as extrinsic content; in the
case of extrinsic content, then the resulting resource is treated
as plain text that is instantiated.

[GA] Describes possible advanced use of "use" in which case an
XML document or a fragment of an XML document could be specified
along with an XSL transform, such that the transform operates on
the referenced content (doc or frag) and produces either plain
text or a TTWG fragment that is valid in the context in which the
use elt is used. For example,

<use>
  <data xlink:href="foo.xml"/>
  <transform xlink:href="foo.xsl"/>
</use>

[SH] other possibility is to use an XQuery expression which can
construct a fragment.

Tentative Resolution: do not try to support XSLT or XQuery
mechanisms described above in TT-AF-1-0 (possible V2 feature).

Example of Uses of <use>:

1. referencing an image in /tt/head/defs:

<head>
  <defs>
    <image id="img1" src="foo.png"/>
  </defs>
</head>
<body>
  <div>
    <p>Foo <use xlink:href="#img1"/> Bar</p>
  </div>
</body>

[SH] Another advanced possibility is to define content fragment
in /tt/head/defs, then reference using <use>. Also useful for
managed/transformed content, e.g.,

<content id="frag1">
  <query xlink:href="foo.xqr"/> <!-- use xquery to extract data -->
</content>
...
<body>
  <div>
    <p>Foo <use xlink:href="#frag1"/> Bar</p>
  </div>
</body>

[DS] What is the expression language/space over which we can
perform content selection?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Review XPath subset proposal [SH]
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Tentative Resolution: Adopt XQuery1.0/XPath2.0 as expression
language for select as well as for select attribute on rule and
cue elts.

Action: [SH] Propose set of functions to be used in content
selection and rule/cue elt's select attr.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hyperlinking Support/Usage
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ intradocument activation supported? link timing model?

Tentative Proposal: Do not support temporal linking semantics,
but do support 

Tentative Proposal: In order to make hyperlinks activatable,
define use of an "activatable" style property (or attribute) on
hyperlink elt (e.g., see XLink). Can use "disabled" to turn off
activatability of hyperlink.

Tentative Proposal: Use "show" property (or attribute) on
hyperlink elt (e.g., see XLink) -- or an equivalent to be defined
-- in order to express semantics of traversal (i.e., what happens
or should happen upon actuation of link).

Tentative Proposal: Define a new temporally oriented XPointer
scheme to support standardized temporal targets. Three types of
targets include: (1) media time in current TT's time line, i.e.,
clock offset; (2) reference to a timing element that can be
resolved to a point on current TT's time line, i.e., syncbase
timing; (3) media marker for context outside of current TT
document, e.g., marker('foo23').

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Timing Schema Module and Example Review
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ applicative versus inline timing - mutually exclusive?

Resolution: Support only applicative or only inline timing,
but not admixture of both.

+ syncbase timing support? is it needed, if so develop use cases

[EH] there is a short sync arc (both elts have same default
syncbase); and a long sync arc (both elts do not share same default
syncbase).

Tentative Resolution: Don't support syncbase timing on basis that
timing containment/sibling structure can be separated from content
containment/sibling structure by use of time sheets. May reopen
if valid use case is articulated that isn't handled by separate
time sheet.

+ eventbase timing support? is it needed, if so develop use cases

Tentative Resolution: Support eventbase timing, with TBD of
specifying events for which we support authoring semantics.

Action: [EH] will propose specific events for which will define.

+ range of values for begin/end; timebase model?

+ support negative offsets?

[EH] Wallclock values can induce negative offsets.

Action: [EH] to check on whether event, accesskey and/or marker,
times can translate to equivalent of negative offsets.

Closed: [EH] reports that event, accesskey, and marker times
only apply if parent is active; meaning that they cannot translate
into negative offsets implicitly (i.e., unless there were an
explicit -offset specified by author, which we are not
supporting.)

Resolution: Not support wallclock times, with the goal
being to dispense with support for negative begin/end times. Need
to verify that event, accesskey, and marker time values cannot
induce negative begin/end time.

+ <excl> support

Action: [GA] Put language in TT-AF-1-0 spec that gives guidelines
about how to represent multiple language documents/fragments.

[GA] Notes that this very likely will not be supported in DFXP.

Tentative Resolution: Support <excl>.

+ <priorityClass>; which attrs? peer, lower, higher, pauseDisplay

Action: [EH] to propose specific attrs|attr values for use with
priorityClass.

+ restart, restartDefault attributes (whenActive, whenNotActive,
never)

[GA] Appears to apply only in case of eventbase timing since
we don't allow multiple explicit begin/end times.

[SH] Notes that multiple <cue> elements can select the same
content elt.

[GA] Asks what default time action should be? Thinks it should
be "display".

[SH] Thinks it should be "none".

[GA] Suggests that we could have a "timeActionDefault" attr
expressed in the timesheet at a high level, e.g., on <timing>
elt.

Open Issue: Investigate how to express time action default.

Action: [GA] Need to define that TT is a continuous media type
with respect to SMIL.

Tentative Resolution: Support restart attributes since we
support eventbase timing.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Day 2 (Wednesday, June 23, 2004)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Decision on LF Only or LF/PF or LF/PF/NF
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ if no PF, what are we losing? is it acceptable?

[GA] losing lower level abstraction in terms of flows/flow/block;
yes, it is acceptable: precompile to other format.

+ if no NF, what are we losing? is it acceptable?

[GA] losing lower level abstraction in terms of area/glyph
specification and placement; yes, it is acceptable: precompile
to other format.

+ if LF only, then develop model for conformance testing, e.g.,
  define transform to XSL-FO or SVG

[GA] reviews layer and profile coverages:

		LF	DFXP	PF	NF

Content		X|I	I	I(C)	I(G)	
Style		A|R|I	R|I	R|I	R|I
Timing		A^I	I	I	I

Key:	A = applicative
	R = referential
	X = external
	I = inline
	I(c) = inline characters
	I(g) = inline glyphs
	| = inclusive or
	^ = exclusive or

Core Content Vocab:

LF   :	body, div, p, span, br
DFXP :	body, div, p, span, br
PF   :  flows, flow, block, inline, br
NF   :  areas, area, glyphs, glyph

Resolution: Drop PF and NF layers, add referential timing
to LF layer. DFXP to be proper subset of LF, sans external
content and applicative styling or timing.

Consensus: DFXP's design center is that it must be readily
compilable into a streaming format.

[SH] Limiting vocabulary in DFXP is not sufficient to make
it streamable; may need other constraints such as limiting
duration of a content element, timing overlap, content region
overlap, etc.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Styling Schema Module and Example Review
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ applicative versus inline styling - mutually exclusive?

Action: [SH] document pseudo-algorithm for translating hybrid
of Applicative + Referential + Inline into Applicative + Inline;
prescribe use of CSS specificity rules or some equivalent
thereof for resolving conflicts.

Action: [SH] propose mapping from space of XPaths to specificity
values.

Action: [SH] propose spec ready text that defines transformation
from referential to inline styling.

Resolution: Mutual exclusion is not required for applicative,
referential, and inline styling; i.e., they can be mixed (at least
in full profile). In DFXP, applicative does not apply, and
referential can be mapped to inline.

+ review open styling issues from previous telecon

Issue: whether to support minimal style elt with ref attribute to
get indirected style definition?

Resolution: Do not support; don't have good use case.

Issue: whether to support tts:content style property?

[SH] Don't use name attr, instead use tts:content="before|after|
replace".

[GA] Supports this change.

Resolution: Support tts:content as an attr on style, in which case
value of tts:content is before, before-inner, after, after-inner, or
replace, replace-inner, and content of style elt is content to be
inserted/substituted. If a rule should select a node set, then
semantics of insertion/ substitution is that it operates only on
element nodes in node set.

Open Issue: [GA] should we permit insertion/substitution for nodes
other than elt nodes? e.g., text nodes?

Open Issue: [DS] how are styles recursively applied after content
insertion/substitution?

Open Issue: [SH] what content can appear under
<style tts:content>...</style>, e.g., is this limited to text
or can it be markup? if markup, then what markup?

Examples:

<style tts:content="before">
<br/>
</style>

<style tts:content="before">
<span xml:lang="fr">Jean dit:</span>
<span xml:lang="en">Go to <span xml:lang="fr">l'enfer</span></span>
</style>

<style tts:content="before" xml:lang="ar">
<span dir="LTR">LTR Span</span>
<span dir="RTL">RTL Span</span>
</style>

<style tts:content="before" xml:lang="jp">
... ruby (furigana) markup ...
</style>

Open Issue: [GA] how to validate before/after
insertion/substition? Will need constraints specified that
control affect on validity.

Constraint #1: Insertion/substitution occurs at infoset and not
at lexical XML layer.

Constraint #2: Selection of nodes in original infoset which are
subject to insertion/substitution occurs once and once only,
and this occurs prior to application of insertion/substitution.
That is to say, selection does not occur iteratively.

Constraint #3: Selection of nodes for non-insertion/substitution
occurs once after insertion/substitution. That is, results of
insertion/substitution are affected by other style applications
(i.e., other than insertion/substitution operations).

Constraint #4: If insertion/substition styles multiply select
the same target node, then insertion/substition shall occur in
specificity resolved order such that insertion always inserts
immediately prior or immediately after selected node independently
of previously inserted content. Furthermore, substitution shall
occur in specificity resolved order and shall always wholly
replace the content of the node independently of whether it has
been previously replaced.

[SH] Proposes *-inner for (before, after, replace).

Constraint #5: Insertions and substitutions must be collected into
change lists, where each node subject to insertion/substitution is
associated with a distinct change list for each type of change.  Once
all insertion/substitution rules have fired, then all change lists
are accumulated into an change application list. Then this
application list is ordered such that any application that applies to
a node N must precede any application that applies to a node N' such
that N is a descendant of N'.

[N.B. This constraint ensures that replacement of a ancestor won't
affect change to a descendant, and that path from descendant
to ancestor will remain intact until all changes to ancestor's
descendants are complete.]

########################################################################

Example #1:

Serialized Pre-Insert/Substitute:

<!-- this rule fires 1st -->
<rule select="#p1">
  <style tts:content="before">Foo</style>
</rule>
<!-- this rule fires 2nd -->
<rule select="#p1">
  <style tts:content="before">Bar</style>
</rule>
...
<p id="p1">Baz</p>

Serialized Post-Insert/Substitute:

FooBar<p id="p1">Baz</p>

########################################################################

Example #2:

Serialized Pre-Insert/Substitute:

<!-- this rule fires 1st -->
<rule select="#p1">
  <style tts:content="before-inner">Foo</style>
</rule>
<!-- this rule fires 2nd -->
<rule select="#p1">
  <style tts:content="before-inner">Bar</style>
</rule>
...
<p id="p1">Baz</p>

START : CL(before-inner) = null
R1    : CL(before-inner) = Foo
R2    : CL(before-inner) = BarFoo
APPLY : insert BarFoo before inner, then clear CL(before-inner)
START : CL(before-inner) = null

Serialized Post-Insert/Substitute:

<p id="p1">BarFooBaz</p>

########################################################################

Example #3:

Serialized Pre-Insert/Substitute:

<!-- this rule fires 1st -->
<rule select="#p1">
  <style tts:content="after-inner">Foo</style>
</rule>
<!-- this rule fires 2nd -->
<rule select="#p1">
  <style tts:content="after-inner">Bar</style>
</rule>
...
<p id="p1">Baz</p>

START : CL(after-inner) = null
R1    : CL(after-inner) = Foo
R2    : CL(after-inner) = FooBar
APPLY : insert FooBar after inner, then clear CL(after-inner)
START : CL(after-inner) = null

Serialized Post-Insert/Substitute:

<p id="p1">BazFooBar</p>

########################################################################

Example #4:

Serialized Pre-Insert/Substitute:

<!-- this rule fires 1st -->
<rule select="#p1">
  <style tts:content="replace">Foo</style>
</rule>
<!-- this rule fires 2nd -->
<rule select="#p1">
  <style tts:content="replace">Bar</style>
</rule>
...
<p id="p1">Baz</p>

START : CL(replace) = null
R1    : CL(replace) = Foo
R2    : CL(replace) = Bar
APPLY : substitute Bar for node, then clear CL(replace)
START : CL(replace) = null

Serialized Post-Insert/Substitute:

Bar

########################################################################

Example #5:

Serialized Pre-Insert/Substitute:

<!-- this rule fires 1st -->
<rule select="#p1">
  <style tts:content="replace-inner">Foo</style>
</rule>
<!-- this rule fires 2nd -->
<rule select="#p1">
  <style tts:content="replace-inner">Bar</style>
</rule>
...
<p id="p1">Baz</p>

START : CL(replace-inner) = null
R1    : CL(replace-inner) = Foo
R2    : CL(replace-inner) = Bar
APPLY : substitute Bar for node's inner content, then clear
CL(replace-inner)
START : CL(replace-inner) = null

Serialized Post-Insert/Substitute:

<p id="p1">Bar</p>

########################################################################

[GA] the above tts:content style won't go into DFXP, however,
it may be used while going from FP (full profile) to DFXP.

Issue: how to resolve duplications of names when creating a union
of styles via style inclusion mechanism (i.e., use attribute)?

[SH] already has action to articulate mapping from referential
styles to inline styles, which will answer this question.

Issue: can use attribute reference multiple elts?

Resolution: use (that is, style) attribute can reference
multiple elts. [N.B. We decided to change "use" to "style"
in general for referencing style groups/elts.]

Issue: how might default regions interact with applicative styling?

Issue: what are default values for region extent/origin if not
specified? [GA] thinks that default origin is [0,0], meaning
same origin as parent, and that default extent is same extent as
parent. If there is no parent, then origin and extent are defined
by outer context. If outer context defines no extent, then default
extent is undefined.

[DB] Asks about meaning of "style" attr, suggests that perhaps
it should be avoided to prevent confusion with traditional
HTML use of attribute.

[DB] Is concerned that TT-AF-1-0 uses "region" in a manner
that is different from SMIL and may cause user confusion.

[GA] Let's focus on self-consistent definitions, then will consider
naming as a post-processing pass (prior to public WD).

Resolution: [DB] Drop "default" attribute on region. A region
attribute may be placed on a content element, in which case it
is taken out of flow from its parent, and the region defines the
allocation rectangle for the element and its flowed children.

If no region is
specified the highest level content element, e.g., <body>, , is
associated with a "default" region that is defined by the outer
context.

Example:

<body>
  <div region="r1">
    <p id="p1" region="r2">
    <p id="p2" region="r3">
  </div>
</body>

body => default flow
div  => r1, but has no content (i.e., p1,p2 goes into r2,r3)
p1   => r2
p3   => r3

Issue: consider eliminating one or attrs for referencing style or
group; at present there are: ref, use, and style attrs.

+ review styling examples for accuracy

+ develop styling examples for properties without examples

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Issues Tracking System
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[GA] demonstrated tracking system.

Action: [GA] populate defect database with current action items
and open issues.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Metadata Module Finalization
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Resolution: Support metadata in TTAF.Description.class.

Resolution: Use name "meta" for name of metadata wrapper element.

Resolution: Support TTAF.Description.class in DFXP as in FP.
[N.B. see digital millenium copyright act which proscribes removal
of (some|all?) metadata.]

[DB] Wonders if we should not define our own actor/character
metadata items, or if so to put in informative annex.

[GA] We should at least include examples of using mpeg7 and
dublin core metadata.

Action: [TM] have MD adhoc review [GA]'s strawman for metadata
items (see tt-af-1-0-metadata-items.rnc), which defines both
actor and character metadata elements. Some potential actions
might be: don't use, use but make informative, use with
modifications, use as is, etc.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Day 3 (Thursday, June 24, 2004)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[*] Length discussion about everything...

[*] Introduce notion of "flow sheet" or "applicative flow".

[*] Introduce analogy of flowContainer/flowAction attrs as
compared with timeContainer/timeAction.

[*] Introduce analogy of "explicit inline flow" attributes as
compared with syncbase timing in SMIL (e.g., attributes that
explicitly express parent and sibling relations).

[*] Introduce idea of "combine" attribute on region or flow that
describes mode for placing content into region/flow. Possible
values discussed include: replace, flow, append, prefixOrder,
postfixOrder, overlay. May also utilize "overflow" attribute to
describe scroll, clip, ... behavior.

[DB] Must be able to express simple cases simply!

*** Lunch ***

[GA] Where are we with actions on previous discussion?

[SH]

New General Information Model


       S     F     T

       |     |     |
	\    |    /
	 \   |   /
	  \  |  /
	   \ | /
	     v

	     C

S = styling; F = flowing; T = timing; C = content

Resolution: don't inline timing, flowing, styling on each other;
only inline on content; i.e., this represents post-application
model wherein timing, flowing, styling are applied to content.

Working Assumption: DFXP is a lexical and semantic subset
of a fully inlined content instance C', where C' is result of
applying:

(.) T F S C => T(F(S(C)))

[GA] Thinks we presently have following covered (modulo
minor details):

1. C      => tt-af-1-0-logical.rnc
2. S,S(C) => tt-af-1-0-styling.rnc, tt-af-1-0-styling-attribs.rnc
3. T,T(C) => tt-af-1-0-timing.rnc, tt-af-1-0-timing-attribs.rnc

[GA] Need to develop following:

1. F,F(C) => tt-af-1-0-flowing.rnc, tt-af-1-0-flowing-attribs.rnc

[GA] Asks: should we support inline styling on out of line flow
sheet? Yes.

Resolution: For TTAF V1, each flow is associated with a single,
anonymous region, with region geometry specified on directly on
flow. May consider separate region elements in V2 with flow being
associated with sequence of regions.

Resolution: As a further refinement of previous resolution that
associates a flow with a single region in TTAF V1, change name
of "flow" elt to "region", which also has side effect of naming
regions.

Resolution: For inline flow/layout, content elements can specify
"region" into which they are to be flowed. If a content element
is not associated with a region (in either applicative or inline
form of flow/layout), then the content is not presented. A
content element is not associated with a region if neither it nor
any ancestor up to <body> contains a region attribute or is
associated with a region via associative flow/layout. If a content
element is associated with a different region than its parent,
then it is removed from the flow of its parent, and is adopted by
the flow of the referenced region, where adoption by referenced
region occurs in terms of the "combine" attribute of the referenced
region.

Open Issue: What styles and attributes can be animated? If animated,
then is only discrete or is continuous animation supported?

Open Issue: The syntax of animate/set require use of attribute
name in "attributeName" attribute. In our case, this means using
namespace qualified names in attribute values.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DFXP Feature Review
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ referential/inline styling only?

[GA] yes; decided both on Day 1.

+ inline timing only?

[GA] no; decided both referential and inline on Day 1.

+ content restrictions?

[GA] unknown at this time.

+ streamability model

[GA] thinks we should write informative language describing
some possible approach to streaming, and discusses shortcomings.

[TM] should we expect implementation of using DFXP as a DF?

[GA] DFXP is not explicitly designed to be a DF; however, it
is not precluded for use a DF, albeit there may be shortcomings
regarding effeciency, streamability, etc. We may want to describe
these in informative language in spec.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Review TT-AF-1-0 Spec Text and Plan Actions
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Action Plan:

 1. [GA] update examples and schema modules.
 2. [GA] incorporate style property examples and text as appropriate.
 3. [GA] incorporate timing property examples and text as appropriate.
 4. [SH]  propose spec ready text that defines transformation
from referential to inline styling.
 5. [SH] propose mapping from space of XPaths to specificity
values.
 6. [SH] document pseudo-algorithm for translating hybrid
of Applicative + Referential + Inline styling into Applicative +
Inline styling; prescribe use of CSS specificity rules or
some equivalent thereof for resolving conflicts.
 7. [SH] Propose set of functions to be used in content
selection and rule/cue/use elt's select attr.
 8. [SH] Propose aural presentation and styling model.
 9. [SH] To check with CSS WG on best way to express text outline
property.
10. [DS] Update scroll module and work with John Birch on
temporal flow mode properties.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Upcoming Meetings
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Action: [GA] query members about moving CC time slot to 2pm
Eastern.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
START SUMMARY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

*** RESOLUTIONS ***

Tentative Resolution: given that it would require considerable
research to determine if and how multiple active timesheets are
well defined, given lack of use case scenarios, given expected
complexity of implementation, conclude that multiple concurrent
timesheet support not be provided in TT-AF-1-0; may be reopened
if someone conducts research to provide definition of semantics
of concurrent timesheets and shows that expected complexity is
justified by fulfilling real use cases.

Corollary Resolution: similarly, do not support multiple non-
concurrent timesheets, due to lack of use cases and expected
implementation complexity.

Tentative Resolution: Permit content selection at the following
levels of granularity:

* head    - styling+
* head    - timing
* styling - rule+
* timing  - (seq|par|excl|cue)+
* content - (div|p|span|a|image|use)+

Tentative Resolution: do not support selection directly on
metadata; note that for content or other elements that can contain
metadata as children, then that content or other elements may be
selectable.

Tentative Resolution: introduce "use" elt to instantiate image
defined in /tt/head/defs as well as extrinsic content; in the
case of extrinsic content, then the resulting resource is treated
as plain text that is instantiated.

Tentative Resolution: do not try to support XSLT or XQuery
mechanisms described above in TT-AF-1-0 (possible V2 feature).

Tentative Resolution: Adopt XQuery1.0/XPath2.0 as expression
language for select as well as for select attribute on rule and
cue elts.

Resolution: Support only applicative or only inline timing,
but not admixture of both.

Tentative Resolution: Don't support syncbase timing on basis that
timing containment/sibling structure can be separated from content
containment/sibling structure by use of time sheets. May reopen
if valid use case is articulated that isn't handled by separate
time sheet.

Tentative Resolution: Support eventbase timing, with TBD of
specifying events for which we support authoring semantics.

Resolution: Not support wallclock times, with the goal
being to dispense with support for negative begin/end times. Need
to verify that event, accesskey, and marker time values cannot
induce negative begin/end time.

Tentative Resolution: Support <excl>.

Tentative Resolution: Support restart attributes since we
support eventbase timing.

Resolution: Drop PF and NF layers, add referential timing
to LF layer. DFXP to be proper subset of LF, sans external
content and applicative styling or timing.

Resolution: Mutual exclusion is not required for applicative,
referential, and inline styling; i.e., they can be mixed (at least
in full profile). In DFXP, applicative does not apply, and
referential can be mapped to inline.

Resolution: Do not support; don't have good use case.

Resolution: Support tts:content as an attr on style, in which case
value of tts:content is before, before-inner, after, after-inner, or
replace, replace-inner, and content of style elt is content to be
inserted/substituted. If a rule should select a node set, then
semantics of insertion/ substitution is that it operates only on
element nodes in node set.

Resolution: use (that is, style) attribute can reference
multiple elts. [N.B. We decided to change "use" to "style"
in general for referencing style groups/elts.]

Resolution: [DB] Drop "default" attribute on region. A region
attribute may be placed on a content element, in which case it
is taken out of flow from its parent, and the region defines the
allocation rectangle for the element and its flowed children.

Resolution: Support metadata in TTAF.Description.class.

Resolution: Use name "meta" for name of metadata wrapper element.

Resolution: Support TTAF.Description.class in DFXP as in FP.
[N.B. see digital millenium copyright act which proscribes removal
of (some|all?) metadata.]

Resolution: don't inline timing, flowing, styling on each other;
only inline on content; i.e., this represents post-application
model wherein timing, flowing, styling are applied to content.

Working Assumption: DFXP is a lexical and semantic subset
of a fully inlined content instance C', where C' is result of
applying:

Resolution: For TTAF V1, each flow is associated with a single,
anonymous region, with region geometry specified on directly on
flow. May consider separate region elements in V2 with flow being
associated with sequence of regions.

Resolution: As a further refinement of previous resolution that
associates a flow with a single region in TTAF V1, change name
of "flow" elt to "region", which also has side effect of naming
regions.

Resolution: For inline flow/layout, content elements can specify
"region" into which they are to be flowed. If a content element
is not associated with a region (in either applicative or inline
form of flow/layout), then the content is not presented. A
content element is not associated with a region if neither it nor
any ancestor up to <body> contains a region attribute or is
associated with a region via associative flow/layout. If a content
element is associated with a different region than its parent,
then it is removed from the flow of its parent, and is adopted by
the flow of the referenced region, where adoption by referenced
region occurs in terms of the "combine" attribute of the referenced
region.

*** OPEN ACTION ITEMS ***

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] Make proposal regarding use of Xlink vocabulary or
"src" attribute.

Action: [GA] Draft new requirement on "Integrability"
in general terms that should not impact testing or implementation
requirements.

Action: [GA] incorporate agreed changes into TT-AF-1-0-REQ in
preparation for publishing final W3C Note.

Action: [SH] will review and propose subset of aural parameters
(see R305).

Action: [GA] Add figure showing logical structure anticipated
by requirements.

Action: [GA] Add note to R217 and R219 that shows use of data: URI
scheme.

Action: [SH] to propose subset with extensions for use in CS
Profile.

Action: [GF] investigate syntax for regions vis-a-vis style.

Action: [DK] To write up short paragraph on uses of
role tokens. Suggest removing or adding as he
progresses.

Action: [TM] to propose and define standard MD attributes. N.B.
Awaiting further discussion by WG.

Action: [DK/MD/TM] Formulate recommendation on specific and general
MD features.

Action: [GA] Need to start planning for September meeting in Japan!

Action: [SH] to draft standard ready text for subset of xquery.

Done. Don't subset.

Action: [DS] Based on email of 01/14, integrate with fillBehavior as
described in example.

Action: [*] For module owners, start developing test suite documents
that have feature tests in all necesary context, and no superfluous
context. Follow-on for primary spec editor will be to incorporate
fragments from these cases, but that will be subsequent to publishing
first internal draft of integrated spec.

Action: [SH] To check with CSS WG on best way to express text outline
property.

Action: [GA] Update schema.

Action: [TM] Update metadata module text.

Action: [SH] Provide draft on or before June meeting to discuss aural
parameters and also related descripive vocabulary, such as shift ...

Action: [GF]/[DK] To collaborate in order to propose (or not) a set of
role values to be standardized, or, if not, then listed in informative
annex.

Action: [*] Please review [1] for consideration as possible mechanism
for performing conditional selection of content, style, timing.

[1] http://www.w3.org/2001/di/Group/di-selection/

Action: [GA] Incorporate strawman use into schema for June revision of
TT-AF spec.

Action: [GA] ensure that head module excludes multiple
timesheets, i.e., at most one timesheet may be selected on a
temporally static basis.

Action: [GA] ensure that styling module provides for selection
of a lexical sequence of rules as opposed to an individual rule.

Action: [GA] ensure that timing module provides for selection
of a lexcial sequence of (seq|par|excl|cue) as opposed to an
individual timing container or cue element.

Action: [GA] ensure that head module admits only one timing
element.

Action: [GA] Contact Daisy absentees of TTWG to see if they want
to promote this. Need them to attend.

Action: [GA] ensure that head schema module supports defs elt
with audio|image|font children.

Action: [SH] Propose set of functions to be used in content
selection and rule/cue elt's select attr.

Action: [EH] will propose specific events for which will define.

Action: [EH] to check on whether event, accesskey and/or marker,
times can translate to equivalent of negative offsets.

Closed: [EH] reports that event, accesskey, and marker times
only apply if parent is active; meaning that they cannot translate
into negative offsets implicitly (i.e., unless there were an
explicit -offset specified by author, which we are not
supporting.)

Action: [GA] Put language in TT-AF-1-0 spec that gives guidelines
about how to represent multiple language documents/fragments.

Action: [EH] to propose specific attrs|attr values for use with
priorityClass.

Action: [GA] Need to define that TT is a continuous media type
with respect to SMIL.

Action: [SH] document pseudo-algorithm for translating hybrid
of Applicative + Referential + Inline into Applicative + Inline;
prescribe use of CSS specificity rules or some equivalent
thereof for resolving conflicts.

Action: [SH] propose mapping from space of XPaths to specificity
values.

Action: [SH] propose spec ready text that defines transformation
from referential to inline styling.

Action: [GA] populate defect database with current action items
and open issues.

Action: [TM] have MD adhoc review [GA]'s strawman for metadata
items (see tt-af-1-0-metadata-items.rnc), which defines both
actor and character metadata elements. Some potential actions
might be: don't use, use but make informative, use with
modifications, use as is, etc.

Action: [GA] query members about moving CC time slot to 2pm
Eastern.

*** 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: 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 (2004-03-05): Whether to allow block as immediate child of
inline? N.B. XSL-FO does allow this. [GA] showed example of renmoji
(horizontal block in vertical Japanese lines).

Issue (2004-05-12): how to interpret NLF, PARA SEP, and LINE SEP?
more general issue is how to interpret UNICODE controls of various
types in DFXP?

Issue (2004-06-24): Investigate how to express time action default.

Issue (2004-06-24): whether to support minimal style elt with ref
attribute to get indirected style definition?

Issue (2004-06-24): whether to support tts:content style property?

Issue (2004-06-24): [GA] should we permit insertion/substitution for
nodes other than elt nodes? e.g., text nodes?

Issue (2004-06-24): [DS] how are styles recursively applied after
content insertion/substitution?

Issue (2004-06-24): [SH] what content can appear under <style
tts:content>...</style>, e.g., is this limited to text or can it be
markup? if markup, then what markup?

Issue (2004-06-24): [GA] how to validate before/after
insertion/substition? Will need constraints specified that control
affect on validity.

Issue (2004-06-24): how to resolve duplications of names when
creating a union of styles via style inclusion mechanism (i.e., use
attribute)?

Issue (2004-06-24): can "use" attribute reference multiple elts?

Issue (2004-06-24): how might default regions interact with
applicative styling?

Issue (2004-06-24): what are default values for region extent/origin
if not specified? [GA] thinks that default origin is [0,0], meaning
same origin as parent, and that default extent is same extent as
parent. If there is no parent, then origin and extent are defined by
outer context. If outer context defines no extent, then default
extent is undefined.

Issue (2004-06-24): consider eliminating one or attrs for referencing
style or group; at present there are: ref, use, and style attrs.

Issue (2004-06-24): What styles and attributes can be animated? If
animated, then is only discrete or is continuous animation supported?

Issue (2004-06-24): The syntax of animate/set require use of
attribute name in "attributeName" attribute. In our case, this means
using namespace qualified names in attribute values.

*** URIs ***

*** NEXT MEETING DATES ***

* Sep 14-16 in Amsterdam (CWI)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
END SUMMARY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Thierry MICHEL
W3C/ERCIM
Received on Friday, 27 August 2004 14:20:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:29 GMT