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

Minutes of TT WG Teleconference on 10/23/03

From: Thierry MICHEL <tmichel@w3.org>
Date: Fri, 9 Jan 2004 18:06:23 +0100
To: <public-tt@w3.org>
Message-ID: <006401c3d6d2$e9b782e0$0200a8c0@wistiti>


Minutes of TT WG Teleconference on 10/23/03

Attendees

  Glenn Adams (XFSI, Chair, Scribe) [GA]
  Sean Hayes (Microsoft) [SH]
  David Kirby (BBC) [DK]
  Dave Singer (Apple) [DS]
  Erik Hodge (RealNetworks) [EH]

Regrets

  Markus Gylling (Daisy) [MG]
  Thierry Michel (W3C) [TM]
  Mike Dolan (Invited Expert) [MD]
  Geoff Freed (WGBH/NCAM) [GF1]

Absent

  Gerry Field (WGBH/NCAM) [GF2]
  Markku Hakkinen (JSRPD) [MH]
  George Kerscher (Daisy) [GK]
  Brad Botkin (WGBH/NCAM) [BB]

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

0. Status on XML Binary Workshop
1. Review Open Action Items
2. Review Open Issues
3. Discuss exit criteria determination
4. Minimum Profile Discussion
5. Continuation of agenda from F2F

************************************************************************
0. Status Report on XML Binary Workshop
************************************************************************

[GA] Describes workshop. Different camps present with distinct
requirements: (1) maximize parsing speed for high transaction
processing rate (binary SOAP); (2) minimize bandwidth for very low
speed or high cost bandwidth scenarios; (3) support streaming and
incremental infoset update. One camp argued (fairly religiously)
against an XML binary format fearing it would dilute interoperability.

Action items out of work shop are to create a task force (or an IG)
to draw up a draft charter and draft requirements documents to
present to AC to request starting a new WG.

[GA] would likely not be able to attend WG, but TTWG would interact
with new WG to input requirements and insure solution meets our
requirements.  Likely that there will be any output until late in
current TTWG charter lifecycle. May come into play if TTWG is
rechartered for DF work as follow on to AF.

************************************************************************
1. Review Open Actions
************************************************************************

Defer

************************************************************************
2. Review Open Issues
************************************************************************

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?

[EH] Researched this issue and didn't find any use case from perspective
of RealNetwork requirements.

[DS] Two layer system might be useful.

[EH] Found they could use SMIL and use separate tracks.

[DS] However this requires separating content.

[EH] Yes. This could be an advanced feature.

************************************************************************
3. Developing Exit Criteria
************************************************************************

[GA] Reviews interoperability issues for exit criteria.

[DS] If two systems are writing to the same distribution format from
TT-AF and they are covering same features, then they should produce
very similar or identical results.

[EH] What about two systems writing to different distribution formats
from same TT-AF source? Do we need to define level of similarity or
sameness at that level?

[DS] Should be close as possible but very hard to specify equivalence.

[EH] In considering what is basic or advanced, probably want to see
what features can be done in all formats. Should put those in basic
profile that are in all input sets. Basic may also have other
features.

************************************************************************
4. Planning Minimum Profile(s)
************************************************************************

[GA] Suggest that [EH], [DK], et al., send their "basic features" list
out to the reflector so we can study and then review.

[SH] May want to say something for those who want to use TT-AF as a DF,
but primary purpose is authoring intent.

************************************************************************
5. Continuation of F2F Discussions
************************************************************************

Defer

************************************************************************
Next Meeting
************************************************************************

[DS] Regrets for 10/30.

10/30/03 - Telecon

************************************************************************
ADJOURNS at 1240h Eastern Time (US)
************************************************************************

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

*** RESOLUTIONS ***

*** 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: [BB] To determine semantics of form-feed (FF) and report back.
To also check on HCR (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.

Action: [EH] and [GF] provide input on features they think are out
of scope for basic profile.

Action: [GA] Make proposal regarding use of Xlink vocabulary or
"src" attribute.

Action: [GF] Investigate whether to use IRIs instead of URIs?
Note: XPointer and Namespaces in 1.1 use IRIs?

Action: [SH] Investigate use of "role" vs "class" attribute.

Action: [GF] and [EH] Investigate need for hierachical region
definitions.

Action: [GA] Investigate selection of non-TT vocabulary for
application of style/timing semantics.

Action: [GA] and [GF] Investigate mechanism for cascading
semantics and whether to support cascading on either or both
logical and presentation flowed vocabularies.

Action: [GA] Investigate writing system relative use of
origin style parameter.

*** 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: 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: 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?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
END SUMMARY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Received on Friday, 9 January 2004 12:13:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:16:41 UTC