Re: DFXP LC Comments - Issue 11 Response; SYMM WG

Dear SYMM WG,
If you require any further follow-up please do so, and if you are 
satisfied with the TTWG response, please acknowledge it by replying to 
this mail and copying the TTWG public mailing list: <public-tt@w3.org> 
<mailto:www-smil@w3.org?Subject=Re:%20Response%20to%20SMIL%202.1Last%20Call%20comment:%202005JanMar%2F0004.html&In-Reply-To=%3C42274EBF.5050108@w3.org%3E&References=%3C42274EBF.5050108@w3.org%3E>
Regards,
Thierry Michel

Glenn A. Adams a écrit :

>Dear Yoshi and SYMM WG,
>	
>Thank you for your comments, [1], on the DFXP Last Call Working Draft
>[2].  The TT WG has concluded its review of your comments and has
>agreed upon the following responses.
>
>If you require any further follow-up, then please do so no later than
>September 1, and please forward your follow-up to <public-tt@w3.org>.
>
>Regards,
>Glenn Adams
>Chair, Timed Text Working Group
>
>************************************************************************
>
>Citations:
>
>[1] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0040.html
>[2] http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050321/
>[3] http://www.w3.org/TR/tt-af-1-0-req/
>[4]
>http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_simple-page-ma
>ster
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-0-1: The SYMM WG is concerned about large scale duplication of
>functionality of existing W3C specifications in the DFXP LC WD document:
>The DFXP specification describes functionality that is already defined
>by other specifications, such as XHTML, CSS, and SMIL.  DFXP should
>re-use these specifications. It should do this without introducing any
>changes to the syntax or semantics in these specifications; whole units
>of related functionality should be adopted.  To make re-use of an
>existing spec clearer to the reader and to avoid making any changes the
>DFXP specification should reference to the original specification
>instead of including an own description of such a feature.  It may
>extend these existing languages whenever its own requirements exceed
>what is already available.  This will be of benefit to content authors
>because they do not need to learn a new language. It will also be
>helpful for implementation of processors because they can re-use
>software components.
>
>Response:
>
>The TTWG believes that DFXP [2] does not duplicate, but, rather, reuses
>existing functionality of existing W3C specifications, and, in
>particular: XML, XHTML, CSS (through XSL), XSL, and SMIL.
>
>In its reuse of vocabulary and semantics from the cited existing W3C
>specifications, certain changes were necessitated and warranted to
>satisfy overall requirements adopted for the Timed Text Authoring Format
>1.0 (see [3]). Among these requirements is R105 Ownership of Core, which
>specifies that core functionality is to be specified by the TT WG:
>
><quote>
>The TT AF specification(s) shall be defined in such a manner
>that core functionality be specified soley by the TT WG or, in the event
>that the TT WG is terminated, its successors within the W3C.
>
>Note: It is assumed that one or more appropriate namespace mechanisms
>will be used to segregate core functionality defined or adopted in the
>TT AF from peripheral functionality defined or adopted by clients of the
>TT AF.
></quote>
>
>In order to satisfy this requirement, the adopted vocabulary is placed
>in the TT Namespace (http://www.w3.org/2004/11/ttaf1) or a sub-namespace
>thereof.
>
>When adopting vocabulary from existing W3C specifications into the TT
>Namespace, the TT WG has taken care to change the usage of that
>vocabulary only in order to satisfy other requirements established by
>[3].
>
>In order to make this reuse of vocabulary more clear, and in order to
>offer explanation of the differences introduced by DFXP, the TT WG
>proposes to add an informative Annex to DFXP that specifies the
>derivation of vocabulary and explains the differences in usage. The TT
>WG believes such an Annex will meet the concerns of authors and users of
>DFXP content and permit them to fully reuse their knowledge of existing
>W3C specifications.
>
>Regarding reuse of existing implementations, a TT WG member has
>indicated that they have successfully reused a subset of an existing
>implementation of XHTML, CSS, and SMIL to support DFXP and did so with
>only minor modifications.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-1-1: The functional distinction between DFXP and AFXP seems
>unclear.  It's hard to understand why there should be two different
>profiles.  It just appears to be complicating the system model.  The
>functional difference between DFXP and AFXP should be explained more
>formally than Figure 1.
>
>Response:
>
>DFXP is a strict lexical and semantic subset of AFXP. Functionally, DFXP
>is restricted to those features that can be reasonably processed by a
>streaming parser as opposed to a DOM based parser. In addition to
>simply embedding in other streaming application content formats, DFXP is
>wholly self-contained, and does not require the use of any external
>resources (such as images, style sheets, time sheets, etc.)  It is
>expected that these constraints will not apply to AFXP.
>
>The TTWG believes that this additional background information is not
>strictly necessary in the DFXP specification, but is more appropriately
>placed in the AFXP specification.
>
>Note: Although producing an AFXP specification has remained a goal of
>the TT WG, it is unclear if there will remain sufficient time in the
>current charter as well as continued commitment of resources by
>participants to accomplish this. The TT WG invites your feedback and
>assistance in helping achieve this goal.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-1-2: The current draft does not mention any specific example to
>explain what kind of legacy formats can be transcoded and how much
>useful that is.  The potential markets and application areas should be
>introduced more specifically.
>
>Response:
>
>DFXP contains an informative reference to the TTAF 1.0 requirements
>document [3], which refers to legacy formats and explains use cases.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-1-3: SYMM WG believes DFXP should primarily serve the purpose to be
>rendered directly i.e. it should not be required to first transcode DFXP
>into a proprietary format for rendering.  DFXP should therefore be
>specified as a distribution format.  It should be designed to be
>delivered to and rendered by a wide range of desktop, embedded and
>mobile terminals.  Such distribution format for TT should integrate well
>at least with SMIL and XHTML.  Preferably, the DFXP specification should
>define in full the integration to SMIL and to XHTML to achieve full
>interoperability.
>
>Response:
>
>DFXP is an implementation of a subset of the requirements adopted by the
>TT WG and documented in TTAF 1.0 Use Cases and Requirements [3].  DFXP
>was explicitly designed as an interchange format suitable for exchange
>amongst existing timed text distribution systems. It was also explicitly
>designed such that it could be directly rendered. The TTWG believes that
>this design is realized in the current DFXP LC WD and that no technical
>change is needed to facilitate such usage.
>
>Regarding integration of DFXP with SMIL and/or XHTML, while such
>integration may be defined in the future, perhaps by the TTWG or perhaps
>by the SYMM or HTML WGs, the TTWG does not believe it is a requirement
>to define such integration at this time in the DFXP LC. DFXP as defined
>by [2] can be directly used by an appropriately enabled SMIL or XHTML
>user agent that supports the DFXP content type and its semantics. No
>additional integration specification is required to accomplish this
>usage.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-3-1: The specification insufficiently defines rules for processing
>and rendering of DFXP content.
>
>Response:
>
>Section 9.3 "Region Layout and Presentation" in combination with Section
>3.2 "Processor Conformance" item (5) fully specify the minimum
>compliance
>rules for presenting DFXP content. Section 3.2 fully specifies all
>conformance requirements for processing in general.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-5-1: It is not visible which vocabulary was newly invented by DFXP
>or introduced from existing standards such as XHTML, CSS, XSL, SMIL.
>The original references of all vocabularies should be arranged in a
>table for readability.
>
>Response:
>
>Accepted. An informative table will be added that provides this
>information for the reader.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-6-1: The parameters for time metric seems to have improved very
>well and sufficient to associate with wide variety of media materials.
>But it would be helpful to understand them correctly if more specific
>examples for each feature were provided.
>
>Response:
>
>Accepted. Examples of use of timing parameters will be added.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-7-1: It appears to be a bad choice to re-define HTML language
>elements div, span, p, br with different semantics as in XHTML.  XHTML
>syntax and semantics should be adopted without making any changes.
>
>Response:
>
>TT-AF 1.0 [3] requirement R105 mandates that all core vocabulary be
>specified by the TTWG, which has been accomplished by using a TT
>specific namespace. The derivation of content vocabulary from XHTML is
>based on the recommendation made by requirement R209. The TTWG believes
>it has made judicious reuse of XHTML vocabulary in a manner that is
>consistent with TT-AF requirements and general practice.  In particular,
>the TTWG does not believe any interoperability problems will derive from
>this usage, and that greater interoperability will derive from
>familiarity.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-7-2: Allowing the root tt element to have timing and styling
>attributes seems redundant.  The right place to hold default values of a
>document would be the body element.
>
>Response:
>
>The use of timing attributes (begin, dur, end) on the /tt element is
>predicated upon the need that certain elements specified in /tt/head, in
>particular, /tt/head/layout/region elements, may have timing intervals
>associated with them in order to construct animation timelines on the
>regions. Since these elements do not appear as descendants of /tt/body,
>there was a need to provide a timing context on a higher level element
>that includes both /tt/body and /tt/head/layout/region. Regarding the
>use
>of certain styling properties as attributes on /tt, specifically
>tts:extent, this property used in this context defines the extent of an
>outer containing region, known formally as the "root container region",
>which is logically equivalent to the page-width and page-height
>attributes expressed on the fo:simple-page-master flow object as defined
>by XSL 1.0 [4].
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-8-1: CSS and XSL:FO are the W3C standards for styling and layout.
>Also DFXP should use CSS or XSL:FO for styling.  It should use both
>exact syntax and semantics of CSS/XSL:FO, and then define its own
>attributes where CSS/XSL specifications are insufficient.  Chosen
>solution must allow a lightweight implementation on constraint embedded
>devices.  In case that CSS is used for styling, it is not good enough to
>use CSS attribute names DFXP, e.g. tt:display, tt:fontFamily.  CSS
>syntax and semantics should be used without changes.  DFXP spec should
>list the CSS properties it supports and reference to CSS 2.1 spec for
>their definition.  To get the CSS working normally and leverage its full
>power the DFXP spec may also adopt the following CSS 2.1 features by
>referencing to CSS 2.1 specs: * syntax and basic data types * selectors
>* assigning property values, Cascading, and Inheritance * media types
>(with possible restriction of the supported media types )
>
>Response:
>
>DFXP is based primarily on XSL expression of styling matter. The
>formatting semantics of XSL are normatively adopted in Section 9.3.2
>where the last paragraph states:
>
>"... then apply the formatting semantics prescribed by [XSL 1.0]"
>
>DFXP employs only a subset of XSL functionality based on requirements
>stated in [3]. The TT WG takes exception with the assertion that DFXP
>must adopt the exact syntax and semantics of either XSL or CSS.  Those
>syntactic and semantics that are applicable to DFXP are adopted wherever
>possible, with divergences only when deemed necessary to meet stated
>requirements. The TT WG notes that there is are many precedents in W3C
>technical specifications of adopting existing solutions when possible
>and then subsetting, supersetting, and modifying as the need arises. For
>example, one only has to consider the evolution of CSS/XSL and
>HTML/XHTML languages to see such design principles in practice.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-8-2: (8.3.12) <namedColor> should reference some other
>specification.  Stable references should be CSS2.
>
>Response:
>
>The TT WG believes that direct specification of named color values is
>technically consistent with CSS2 conventions, and believes there is no
>merit in forcing authors to resolve external references for such a
>straightforward and stable enumeration.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-9-1: CSS and XSL are the W3C standards for styling and layout.
>Also DFXP should use either CSS, XSL or SMIL layout.  DFXP may define
>its own attributes where CSS/XSL/SMIL specifications are insufficient.
>Chosen solution must allow a lightweight implementation on constraint
>embedded devices.
>
>Response:
>
>DFXP is based on XSL layout semantics as described above, but is
>extended to meet the requirements documented in [3]. The TT WG believes
>that it is possible to demonstrate "lightweight" implementations of DFXP
>content and/or presentation processing.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-9-2: Allowing timing attributes to be placed in layout elements
>seems interesting, but it could complicate timing structure of a
>document.  Its necessity should be explained reasonably.
>
>Response:
>
>Agreed. Additional explanatory material and examples will be added.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-9-3: Allowing style elements to be placed as a child of a region
>element seems redundant.  Allowing style attributes to be placed in a
>region element would be sufficient.
>
>Response:
>
>Allowing separation of styles into distinct style child elements as
>opposed to mandating their merger provides additional flexibility for
>authoring tools and transformation processors that may wish to isolate
>individual styles and refer to them individually via referential
>styling.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-10-1: DFXP should use a subset of the SMIL 2 Timing and
>Synchronization Module functionality.  It should use exact syntax and
>semantics of SMIL.
>
>Response:
>
>DFXP is based on a subset of SMIL2 timing as document in Section 10.4:
>
>"The semantics of time containment, durations, and intervals defined by
>[SMIL2] apply to the interpretation of like-named timed elements and
>timing vocabulary defined by this specification..."
>
>DFXP departs from the exact syntax and semantics only when requirements
>dictate such departure. The TT WG takes exception to the notion that
>DFXP must adopt the exact syntax and semantics of SMIL. DFXP is a
>distinct media type, and is not intended to replace or alter the
>functionality of SMIL. Its re-use of timing formulations already adopted
>in SMIL is merely a convenience for authors that have current
>familiarity
>with SMIL concepts.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-12-1: The metadata attributes should be introduced from or
>reference to industry standards or existing specifications.  DFXP should
>not develop its own attribute set as a normative part of a
>Recommendation.
>
>Response:
>
>Careful consideration was given to the possibility of direct use of
>existing metadata vocabulary, in particular, the vocabulary defined by
>Dublin Core. In the final analysis, it was determined that the
>requirements of DFXP did not match those provided by similar Dublin Core
>vocabulary. As a consequence, a very limited set of metadata vocabulary
>was defined to meet the specific needs of DFXP content authors in
>creating interoperable content with agreed upon meaning.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>SYMM-12-2: The places for metadata should be limited within a head
>element.  SMIL already provides a good example:
>
>http://www.w3.org/TR/SMIL/metadata.html#smilMetadataNS-example
>
>Response:
>
>The TT WG does not agree with this assertion, and believes that there
>are many use cases for the direct incorporation of metadata into
>content. Common examples of such usage are prevalent in existing W3C
>standards, such as XHTML, SMIL, and SVG in their use of title and
>description attributes or elements. Similarly, XML Schemas provides the
>xs:documentation element type for author supplied metadata.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>Appendix B: Dynamic Flow Processing Model
>
>SYMM-B-1: Text and diagram should be provided.
>
>Response:
>
>Agreed. Either this information will be provided or the feature will be
>removed.
>
>***********************************************************************
>
>Comment: Issue #11 [1]; 25 Apr 2005 22:24:32 +0900
>
>Appendix H: Acknowledgments
>
>SYMM-H-1: Listing former/inactive members seems inappropriate. (It looks
>like accusing specific individuals.) That paragraph should be removed.
>
>Response:
>
>The intent of this comment is unclear. If specific persons listed thus
>would like to have their names removed or attributed in a different
>manner, then such specific request will certainly be accommodated.
>
>***********************************************************************
>
>
>
>  
>

Received on Friday, 12 August 2005 22:27:36 UTC