- From: Thierry MICHEL <tmichel@w3.org>
- Date: Fri, 9 Jan 2004 18:06:23 +0100
- To: <public-tt@w3.org>
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