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

Dear Yoshi and SYMM WG,

Thank you for your responses [1] to our initial response [2] to your
comments [3] to DFXP WD LC [4]. The TT WG has carefully considered
your further comments and follow-on responses, and has agreed to the
following follow-on responses, which are labeled with "TT WG Response
07.10.2005". To reduce clutter, we have remove from below the
following comments for which you had no further response or comment:
SYMM-1-2, SYMM 5-1, SYMM 6-1, SYMM 9-3.

At this time, we do not expect any further responses from the SYMM WG;
however, you are free to comment or respond further if desired.

Regards,
Glenn

------------------
Glenn Adams, XFSI; Cambridge, MA; (e) glenn at xfsi dot com
Chair Timed Text Working Group (TT WG)
------------------

Citations

[1] http://lists.w3.org/Archives/Public/public-tt/2005Sep/0001.html
[2] http://lists.w3.org/Archives/Public/public-tt/2005Aug/0015.html
[3] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0040.html
[4] http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050321/
[5] http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030915/
[6] http://www.w3.org/TR/2001/REC-xsl-20011015/

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

General:

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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

This may be a new comment, and not a further response.

The TT WG believes that DFXP satisfies both the ability to render
directly as well as perform transcoding or interchange with existing
format. Both of these capabilities have been demonstrated.

The goal of interchange was clearly obtained by the adhoc AAF/EBU work
during the recent IBC conference where the EBU STL subtitling format
was transcoded to DFXP, which was then transmitted to two clients
that rendered the result after internally transcoding DFXP back to
the clients' internal formats.

DFXP can also be directly rendered by a client, as has been
demonstrated by a TT WG member company.

An implementation report is expected to be provided as part of the
exit criteria from a DFXP CR, but is not required to advance from LC
to CR.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

This may be a new comment, and not a further response.

The TT WG agrees that at least two implementations should validate the
specification (*); however, the TT WG respectfully disagrees with the
claim that "an implementation that uses transformations is not good
enough".  Furthermore, the TT WG does not agree that a native
rendering requirement should or must be part of the exit criteria.

(*) The TT WG is considering normatively including in DFXP reference
software that implements certain features; in addition, the TT WG has
not fully discussed or finalized the exit criteria it will use with a
DFXP CR; such criteria are expected to be finalized when publishing a
CR.

The SYMM WG offers no evidence that such a requirement would better
validate the specification than a transformational approach. The TT WG
believes that it can be shown that a pure transformational
implementation can satisfy all technical requirements of the
specification and satisfy the requirements from which the
specification was derived. Nevertheless, it is expected that one or
more implementations that render DFXP content directly will be cited
in an eventual implementation report when DFXP is advanced from CR to
PR.

In general, we believe that any implementation that respects the
semantics of DFXP is acceptable, independently of how the
implementation operates. We believe that it is common for any kind of
rendering component to transform content into internal structures that
are implementation dependent. As a consequence, it is not evident how
to distinguish between a transformational implementation and a direct
rendering implementation in the case that the final output is a visual
presentation.

It is important to recognize that there are different types of
processing models that may apply to DFXP and that each of these has
its own semantic scope. The DFXP LC WD [4] identifies a general set of
processor conformance requirements in Section 3.2, Processor
Conformance, and additionally identifies a specialized form of
processing labeled as "presentation processing". It is expected that
DFXP processors that perform a so-called "direct or native" rendering
of DFXP must comply with the "presentation processing" requirements as
indicated in Section 3.2 item (5). However, other types of processors
that do not claim to support presentation processing need not satisfy
this item (5), but need satisfy the other processor conformance
requirements. It is expected that a purely transformational processor
would fall into this latter category.

The TT WG believes that both of these types of processors may be cited
in an implementation report and used to satisfy exit criteria from CR.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

This may be a new comment, and not a further response.

The TT WG believes that it is a time tested process for a W3C WG to
produce a detailed set of technical requirements which are believed to
satisfy some or all of the chartered work of the WG and to then use
those requirements to drive the technical process.

The TT WG published its requirements document as a public WD far in
advance of the publishing of DFXP. All comments on the requirements
document were processed according to W3C Process and their resolutions
recorded.

The TT WG respectfully disagrees that "the TT WG's own requirements
document does not give legitimate justification for DFXP technical
choices". The process used by the TT WG follows a time honored
engineering tradition of developing solutions from requirements and
then using those requirements to justify the results.

It is not clear what alternatives exist to the process taken by the
TT WG, and what might provide a more "legitimate justification".

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

This may be a new comment, and not a further response.

The TT WG believes that it does not duplicate functionality but rather
reuses (subsumes) functionality as suggested by the comment. The
TT WG believes this is accomplished in a manner consistent with the
many other reuses of technology employed by and defined by the W3C.

Such examples come to mind:

* XML reuse and reformulation of SGML syntax and semantics;
* XHTML reuse and reformulation of HTML vocabulary;
* XSL reuse and reformulation of CSS style vocabulary;
* SMIL reuse and reformulation of HTML hyperlinking and metadata
  vocabulary, as well as CSS style vocabulary;
* SVG reuse and reformulation of both HTML and SMIL vocabulary;

The TT WG believes its approach to defining DFXP is consistent with
the history of development and formulation of many other W3C
recommendations, and, as such, is perfectly suited to satisfying the
requirements for DFXP and the charter for the TT WG.

Finally, in no case has DFXP included text from other W3C
specifications by a "copy-paste-transform" process. All content of the
DFXP specification has been originally drafted by the authors and the
editor.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

This may be a new comment, and not a further response.

The TT WG believes that DFXP is integrable with both SMIL and XHTML
without further technical specification. SMIL may use DFXP via the
<text/> element type defined by the media module. XHTML may use DFXP
via the <object/> element type. If there are additional technical
requirements for integration, then the TT WG is not aware of them.

The TT WG is open to members bringing forward proposals that detail
alternative means for integration. The TT WG remains open to
developing technical requirements and specifications to satisfy
additional needs provided that time and resources are available.
The TT WG welcomes participation by interested parties.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 TT WG believes that DFXP [4] 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 [5]). 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
[5].

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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

See responses to comments G-3 and G-4 above.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 TT WG 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

Agreed. All references to AFXP will be removed.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 [5].
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 TT WG
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 TT WG or
perhaps by the SYMM or HTML WGs, the TT WG does not believe it is a
requirement to define such integration at this time in the DFXP LC.
DFXP as defined by [4] 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

See response to comments G-1 and G-5 above.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

See response to comment G-1 above.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 [5] requirement R105 mandates that all core vocabulary be
specified by the TT WG, 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 TT WG
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 TT WG 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

See response to comment G-3 above.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 [6].

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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

The TT WG agrees that the styling and timing attributes that appeared
on the <tt:tt/> root document element can (and will) be relocated to
the <tt:body/> element.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 [5]. 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

See response to comment G-4 above.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

The set of adopted named colors in the DFXP LC WD are a proper subset
of the named colors specified for use with CSS2. Due to other comment
resolutions, the TT WG has agreed to include the "cyan" and "magenta"
named colors in addition to those specified in the LC WD. This was
done to accommodate the common usage of these names in the expected
domains of use. This new set is a proper subset of the named
colors specified by SVG 1.0; therefore, a note that indicates this
fact will be added.

See also response to comment G-4 above.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 [5]. 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

An implementation report will be provided as an exit criteria from
DFXP CR to PR. Such report is not required to advance from LC to CR.

See also response to comment G-1 above.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

The TT WG expects to request transition to CR and expects to include
this explanatory material in the CR. An informative appendix that
notes changes from LC to CR will be provided in the CR for reference.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

The TT WG thanks the SYMM WG for its work in producing the Timing and
Synchronization Module in SMIL 2.0, which has permitted the TT WG to
reuse this functionality in a manner we believe to be congruent with
SMIL.

See also response to comment G-4 above.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 metadata 
vocabulary. This concern remains.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

It is not mandatory that an author use the metadata items defined for
use with DFXP. An author may use any metadata vocabulary desired
provided it is appropriately name space qualified.

If, on the other hand, an author wishes all DFXP implementations to be
able to understand the semantics of certain metadata, such as agent
attribution or content role, then an author may prefer to use the DFXP
defined metadata vocabulary. An author can also use a combination of
the DFXP defined metadata vocabulary and any other metadata vocabulary
in another namespace.

The TT WG believes these limited metadata definitions provide an
integral value to DFXP and satisfy defined requirements.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 TT WG 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 TT WG charter.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

The TT WG believes that it has not defined a new metadata
architecture; furthermore, it is believed that DFXP does "follow the
lead of other W3C specifications" in its support for arbitrary
metadata.

The TT WG is open to specific technical improvements in its defined
usage.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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.".

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

If the feature (dynamic flow processing) is removed, then a diagram
would not be required. [The point being is that it is not certain what
the risk status of this feature is at this time, and that it may be
labeled as being at risk for removal at the end of a CR phase.]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Comment: Issue #11 [3]; 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 TT WG 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 ... ".

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TT WG Response 07.10.2005

The TT WG believes that there is no single convention being used in
the W3C for acknowledgements. However, to address this comment, we
will adopt the suggestion to enumerate current and former members in a
single paragraph without distinguishing their current status as active
or inactive. In addition, we will enumerate the primary "Contributing
Authors" in the document preamble.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Received on Friday, 7 October 2005 20:59:13 UTC