DFXP LC Comments - Issues 6, 7, 9, 13 Responses; Al Gilman

Dear Al,

Thank you for your comments, [1] through [4], on the DFXP Last Call
Working Draft. 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/0024.html
[2] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0036.html
[3] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0038.html
[4] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0043.html

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

Comment - Issue #6 [1]; 11 Apr 2005 10:50:18 -0400

Thank you for offering us the chance to refine our input for a little
longer.

Since you are meeting face-to-face, let me offer the following thoughts
of an individual and preliminary nature.

Key thoughts:

- if the user can receive the content on a programmable device, we
need to develop the [Web] distribution options and content
constraints [with format support] to serve alternative (adaptive)
presentation for individuals.

- there is going to be a lot of content that sees the light of
intra-broadcast-industry pipelines in DFXP encoding.  Deferring
adaptive use to the availability of an AFXP spec is not necessarily
an acceptable policy from the standpoint of disability access.

While the DFXP specification may not define a CPE player for the format
per se, there is still reason to consider use cases for people with
disabilities which require an alternate presentation of the material.

Just because there is no anticipation that the DFXP would be used
directly in mass-market set-top-box processes, it doesn't mean that
there aren't authoring-time requirements on the content that should
be supported in the intermediate form i.e. the DFXP.

Making the DFXP available to a transcoder of the user's choice is
one way that the content encoded in the DFXP could be served to
a person with a disability requiring alternate presentation.

Or the content could be browsed offline using a mainstream XML reader
and a schema-aware assistive technology.

[start use scenario]

Here is a scenario sketch to illustrate what I mean:

There is a meeting held by videoconference over a corporate extranet.
To serve strategic partners in other countries and technology
platforms, Internet technologies are used including subtitles generated
in real time and distributed using DFXP as an intermediate form.

One of the people whose job requires interacting with the content of
the meeting is Deaf and blind.  So a complete log of the meeting is
kept for this participant's offline review.

supposition:  The DFXP, as an XML format, is the dataset of choice
on which to base this person's browse of what transpired in the
session.  Not just the formal statement of the decisions that were
reached, but the dialog that led to the decisions.

This would mean that the DFXP would be spooled and archived with
the audio and video.  Quite possibly there would be a SMIL wrapper
created as a replay aid.  But the deaf-blind user would be reviewing
this through a refreshable Braille device and primarily reviewing the
timed text as transcript.

Note that in interactive Braille as the delivery context,
right-justification
and color are not appropriate as speaker-change cues.  So we
need the speaker-change semantics available, separable from any
particular visual-presenation effects.  DFXP gives the author the
capability to express this, but will the information be there in
instances?

So regardless of whether a collated transcript is created by a
transcoder, or the several text streams are browsed as is with an
adaptive user agent, the availability of speaker identification in
the DFXP instance, the working base for the adapted use, or at a
minimum speaker-change events if the identity of the speakers was not
captured, would be important in affording this user comparable quality
of content as those receiving the same information as real-time
display integrated with the video and audio.

[end use scenario]

This is just to illustrate that there are people with disabilities for
whom
the introduction of something like the DFXP into the content pipelines
of broadcast happenings reflects an opportunity that should not be
wasted to raise the level of service and lower the cost of delivering
that service.

In particular, the use cases for adapted presentation do not necessarily
presume that the DFXP would be pushed to all consumers in the
broadcast bundle.  The distribution protocol might be on an ask-for
or 'pull' basis.   And the user interaction might be in non-real-time
after the fact and not at speed.

But the non-availability of the AFXP format as a "source in escrow"

format for adapted uses means that the user needs the DFXP that
gets produced to be as fit an adaptation basis as we can make it.
This will be true while the AFXP is undefined, and will still be true
for those situations where a copy of the DFXP can be obtained
and a copy of a standard, XML source for that content cannot.  The
latter is likely to be common even after the AFXP has been
specified by W3C.

Thank you (the whole group) for bringing this important technology
this far.  Best wishes for your meeting.

Response:

Thank you for your comments.

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

Comment - Issue #7 [2]; 13 Apr 2005 10:23:29 -0400

The usual approach in W3C is to use consensus public formats as a
pivot point so that the author can understand the binding of the
content schema to the lingo of the domain sourcing the content, and
the assistive technology or device independence specialist can
understand how to map the content schema to the presentation
possibilities of one or another delivery context. The content schema
is consolidated through an inter-community negotiation; while the
pool of people engaged in the negotiation need to cover the
stakeholding domains of activity, nobody has to become an expert in
both/all of them.

http://www.w3.org/2004/06/DI-MCA-WS/

On the other hand, with the Semantic Web the W3C gives us an alternate
approach with less reliance on standard formats and more reliance on
metadata.  And the WAI seeks creative solutions using any applicable
technology, not simply rote cant.

However, a metadata approach would still require that the content
sourcing
activity a) capture and be prepared to share key information such as
speaker identity, where readily achievable, and b) explain the terms
in the way *they* are using [whatever format they are using as the
source or editable form] in terms of well-established public-use
references. The later is a schema reconciliation or data thesaurus.
[There is no policy-free solution, AFAIK.]

The avenue of amelioration that we haven't touched on specifically
has to do with the CR checklist. We should be looking at what
concrete example-use activities during CR would illuminate the issues
we have been discussing so as to make it easier to come to consensus
that the DFXP does about what it should in these directions.

Response:

Thank you for your comments.

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

Comment - Issue #9 [3];	21 Apr 2005 13:24:18 -0400

The following three information elements defined in your metadata
provisions[1] would appear to replicate capabilities available from
the Dublin Core[2].


        12.1.2 ttm:title
        12.1.3 ttm:desc
        12.1.4 ttm:copyright

Please consult with the Dublin Core Usage Board or some expert well
versed in their opinions to see if the information intended to be
conveyed by these three elements is adequately expressed by existing
Dublin Core terms. If there are expressions in terms of Dublin Core
terms that convey what you need to convey, please use them.

Response:

The TT WG believes that (1) it is important to define standard,
interoperable vocabular to express title, description, and copyright
information, and (2) that is important for DFXP, as a basic profile,
to maximize self-containment of vocabulary definitions and usage,
particular for expressing standard interoperable information;
therefore, the TT WG prefers to retain these vocabulary. Recognizing
that there will be some interest in use of DC, we will add informative
information that indictes the corresponding DC vocabulary that may be
addditionally used by authors to express this information.

Finally, the TT WG has carefully reviewed the semantics and intended
use cases of the above three metadata elements and compared these with
similarly named items in the Dublic Core vocabulary. After this
review, we concluded that there is sufficient difference of usage and
intended semantics to retain these items in the TT AF metadata
vocabulary. The DC metadata vocabulary may be used along side this
vocabulary as desired by an author.

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

Comment - Issue #13 [4]; 25 Apr 2005 14:56:43 -0400

<background>

Please refer to the 'ttm:role' attribute as defined in the curent
Timed Text DFXP specification.

http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050321/#metadata-attribute-rol
e

A caucus of WCAG and UAAG participants concluded that they might want
an explicit 'transcription' value for such a role.

http://lists.w3.org/Archives/Member/w3c-wai-cg/2005AprJun/thread.html#35

</background>

<comment>

User agents need clear indications in the format of what text
corresponds to speech in some corresponding audio segment. This is
needed in order for the User Agents to satisfy UAAG Checkpoint 2.3.

http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content

We realize that the DFXP will most often be transcoded into another
format before transmission to the User Agent. However, in order for
the transmitted form to have this information, the distribution format
must be clear on this point for the transcoded results to convey the
right information.

Is this information recognizable from the existing format as it
stands?  If so, how?

Or should the 'ttm:role' attribute have a value of 'transcription'
defined?

</comment>

Response:

We are not certain we understand this comment. DFXP does not
intrinsically support a conditional content construct, such as
described by the DI Select working draft
(http://www.w3.org/TR/2005/WD-cselection-20050502/).

Nonetheless, if we construe that this comment is essentially asking
for an additional standard enumeration value for the attribute
ttm:role of "transcription", then the response is: yes this value can
and will be added to the enumeration found in section 12.2.2 of the
DFXP Last Call WD.

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

Received on Friday, 12 August 2005 19:41:28 UTC