W3C home > Mailing lists > Public > public-tt@w3.org > April 2005

RE: Coments - last call draft (design forward first?)

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Mon, 11 Apr 2005 10:50:18 -0400
Message-Id: <p06110402be803622e0c6@[10.0.1.2]>
To: <public-tt@w3.org>
Cc: "Charles McCathieNevile" <charles@sidar.org>

At 10:02 AM -0500 4/1/05, Glenn A. Adams wrote:
>Thanks Al, this is useful input. I am drafting a longer response on the
>issue of defining UA Behavior that I expect to send this evening or
>tomorrow. However, in the mean time, I want to point out that it was NOT
>a requirement for AFXP or DFXP that it be delivered to a user agent. In
>particular, the system model for TTAF does not include a user agent;
>rather, it posits a subsequent transformation process to an actual
>distribution format that is wedded to a UA. At the same time, neither
>AFXP nor DFXP are precluded from direct distribution, nor from direct
>presentation by a UA; on the other hand, the task of defining such a
>usage was not included in the requirements, and is, at present,
>considered to be largely out of scope for the current chartered work.

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.

Al

>Regards,
>Glenn
>
>>  -----Original Message-----
>>  From: Al Gilman [mailto:Alfred.S.Gilman@IEEE.org]
>>  Sent: Friday, April 01, 2005 9:40 AM
>>  To: public-tt@w3.org
>>  Cc: Charles McCathieNevile
>>  Subject: Re: Coments - last call draft (design forward first?)
>>
>>
>>  At 11:46 AM +1000 3/31/05, Charles McCathieNevile wrote:
>>  >1. Meeting requirements
>>  >
>>  >[[[
>>  >
>>  >It is intended that a more feature-rich profile, known presently as
>>  >the Authoring Format Exchange Profile (AFXP), be developed and
>>  >published to address the full set of documented requirements.
>>  >
>>  >]]]
>>  >
>>  >Is there any concrete reason to believe this will take place? The
>>  >group has had its charter extended already, just to produce this
>>  >restricted draft. Is the group working on this more complete version
>>  >already? Or is this just a hope?
>>
>>   From an accessibility perspective, the following are not unreasonable
>>  to expect:
>>
>>  1 [constraint] The DFXP, if processed through disability-adaptive
>>  presentation transforms, must achieve a functional user experience.
>>
>>  2. [preference] The DFXP should contain, fully modeled, all the
>>  information in the AFXP needed for deriving alternate look and feel
>>  bindings adaptive for diverse people with disabilities [not just
>>  sighted, Deaf people].
>>
>>  2 [prognosis] Deriving disability-adaptive look and feel from the
>>  AFXP will produce more usable user experiences than deriving
>>  disability-adaptive look and feel from the DFXP, given the current
>>  order of freezing the profiles.
>>
>>  3 [prognosis] Experience with disability-adaptive alternative
>>  presentations of AFXP content will make clear places where we should
>>  have done things differently in the DFXP.
>>
>>  So some concern about the freezing of the DFXP to a PR before
>>  completing the CR experience with the AFXP is natural from an
>>  accessibility perspective.
>>
>>  In terms of meeting requirements, the possibly under-explored use
>>  case is one where the DFXP is delivered directly to a player (User
>>  Agent) running on a Customer Premises Equipment computer -- is the
>>  display and control of the text stream suitably adaptable in this
>>  case?
>>
>>  Al
>>
>>
>>
Received on Monday, 11 April 2005 15:07:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:33 GMT