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

Dear Glenn and TT WG,

Thank you for your response to our comments.  SYMM WG will review your 
response and send back further comments if we have.

Regards,
Yoshihisa Gonno
Co-chair, SYMM Working Group

Glenn A. Adams wrote:
> 
> 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.
> 
> ***********************************************************************
> 
> 
> 
>