DFXP LC Comments - Issue 11 Response; SYMM WG

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 20:14:44 UTC