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

Dear Glenn and TT WG,

SYMM WG reviewed the TT WG's response to its DFXP LC WD comments during
its face-to-face meeting on Sept 16. We like to thank the TT WG for
their response and apologize for the delay of our reply. Please find our
reply attached below.

Best regards,
Yoshi

---------------------------------------
Yoshihisa Gonno, Sony Corporation
Co-chair of W3C SYMM WG
email: ygonno@sm.sony.co.jp

***********************************************************************

General:

G-1: G-1: The DFXP specification should define a format that is 
primarily for native (direct) rendering. DFXP should provide an 
alternative to proprietary timed text formats and should not be designed 
for converting to such formats. The charter calls for an alternative to 
proprietary formats, not a mapping to proprietary formats.

G-2: We think there should be two native implementations to validate the 
specification achieves interoperability. An implementation that uses 
transformations is not good enough. The SYMM WG recommends strongly that 
such native rendering requirement should be part of the exit criteria 
for DFXP CR. Two independent implementations, which perform native 
rendering, should be required for each DFXP feature.

G-3: The SYMM WG believes referencing to the TT WG's own requirements 
document does not give legitimate justification for DFXP technical 
choices. The requirements document is not a W3C process document, it has 
not been accepted by the W3C membership.

G-4: The SYMM WG is not satisfied with the way DFXP uses existing W3C 
specifications. It should not duplicate functionality but it should 
subsume functionality; the existing technology must be left intact. DFXP 
approach can be described as "copy-paste-transform", this is not a 
suitable approach

G-5: The TT WG does not feel that direct integration with SMIL or HTML, 
is their responsibility, it shifts the burden to individual WGs. We are 
surprised by this response because it does not follow their charter. 
This is unfortunate because will lead to multiple, incompatible 
implementations.  SYMM will need to address the integration of timed 
text into SMIL as part SMIL NG.


***********************************************************************

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 solely 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.


SYMM WG reply 16.9.2005:

As commented above reference to its own requirements document does not 
give legitimate justification for technical design choices. DFXP should 
leave existing W3C technology intact, the proposed informative Annex 
does not solve the issue.


***********************************************************************


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.


SYMM WG reply 16.9.2005:

All references to AFXP should be removed from the DFXP specification, 
since AFXP is not defined in any approved W3C document.

***********************************************************************


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.


SYMM WG reply 16.9.2005:

Thank you. We have no more comments.

***********************************************************************


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.


SYMM WG reply 16.9.2005:

We commented about the integration of DFXP into other languages in our 
general comments already.  We are looking forward to see native 
rendering of DFXP be verified by two independent implementations, see 
our recommendation on CR exit criteria.


***********************************************************************


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.

SYMM WG reply 16.9.2005:

We are looking forward to see native rendering of DFXP be verified by 
two independent implementations, see our recommendation on CR exit criteria.


***********************************************************************


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.



SYMM WG reply 16.9.2005:

Thank you. We have no more comments.

***********************************************************************


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.


SYMM WG reply 16.9.2005:

Ok, thank you!

***********************************************************************


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.


SYMM WG reply 16.9.2005:

As commented above reference to its own requirements document does not 
give legitimate justification for technical design choices.


***********************************************************************


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].


SYMM WG reply 16.9.2005:

We are not satisfied with the response. Our architectural concerns 
remain. If DFXP was integrated to SMIL the timing information for the TT 
document would need to specified in SMIL. It remains unclear how the 
proposed mechanism would work when integrated to (x)HTML.

We look forward to see test cases as part of the DFXP test suite that 
verify necessity of this feature.


***********************************************************************


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.


SYMM WG reply 16.9.2005:

As commented before technology should be adopted by reference not by 
"copy-paste-transform" re-use, please see general comments above.


***********************************************************************


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.


SYMM WG reply 16.9.2005:

As commented before technology should be adopted by reference not by 
"copy-paste-transform" re-use, see general comments above.

***********************************************************************


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.


SYMM WG reply 16.9.2005:

We are looking forward to having the TT WG response verified by actual 
implementations.

***********************************************************************


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.


SYMM WG reply 16.9.2005:

Thank you. We are looking forward to review another draft.


***********************************************************************


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.


SYMM WG reply 16.9.2005:

Thank you, we have no more comment.

***********************************************************************


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.


SYMM WG reply 16.9.2005:

As commented before your requirements documents does not provide you 
with legitimate justification for technical choices. To say  "Its re-use 
of timing formulations already adopted in SMIL is merely a convenience 
for authors that have current familiarity with SMIL concepts."  violates 
the TT WG charter and is against W3C guidelines to re-use functionality 
of existing specs.


***********************************************************************


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.


SYMM WG reply 16.9.2005:

Our main concern is about DFXP introducing its own mandatory meta data 
vocabulary. This concern remains.


***********************************************************************


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.

SYMM WG reply 16.9.2005:

The utility of metadata markup within a document content part remains an
open issue. The TTWG should follow the lead of other W3C specifications,
since the SYMM WG feels that defining new metadata architectures is
beyond the scope the scope of the TTWG charter.

***********************************************************************


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.


SYMM WG reply 16.9.2005:

The diagram should be required. We do not understand what you mean by 
"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.


SYMM WG reply 16.9.2005:

The SYMM WG feels that TTWG should follow W3C convention. All TT WG 
members who have been involved in the production of the spec should be 
listed regardless of their status at the time of publication. The 
paragraph should say "... current and former WG members are ... ".

***********************************************************************