RE: Coments - last call draft

See inline below.

> -----Original Message-----
> From: Charles McCathieNevile [mailto:charles@sidar.org]
> Sent: Friday, April 01, 2005 2:08 AM
> To: Glenn A. Adams; public-tt@w3.org
> Subject: Re: Coments - last call draft
> 
> On Fri, 01 Apr 2005 00:54:41 +1000, Glenn A. Adams <gadams@xfsi.com>
> wrote:
> 
> On the other hand accessibility issues are not addressed by FO. It is
not
> at all clear how a user should expect to provide styling rules to meet
> their particular needs, as is trivial using CSS for text styling.
> 

[GA] Just because XSL FO does not address accessibility issues per se
does not mean that it doesn't support or that it precludes accessibility
features. XSL FO, like DFXP, does not define a UA or UA behavior. That
means that if one wishes to standardize a UA or UA behavior, then it is
necessary to write an additional specification of that behavior. One
could, if so desired, write a specification for an XSL FO UA or a DFXP
UA, which would reference the normative content specifications of XSL FO
and DFXP, respectively, and then define UA specific semantics or
features layered on top of the content specifications.

[GA] I personally believe that there is great value in separating a
content specification like XSL FO or DFXP from a UA specification. Of
course, if you are an end-user that is looking for standard UA behavior,
then your focus may be more on the latter. However, the latter is not
very useful without the former.

[GA] In the case of DFXP, it is useful to review how the TT WG arrived
at this point. Very early in the deliberations of the TT WG, a key
consensus point reached was that there are many types of existing
distribution formats and user agents for subtitling and captioning
content, particularly as deployed in broadcast television. These
include, in the US, the Analog and Digital Closed Captioning Standards
(CEA-608 and CEA-708, respectively), and, in Europe, the use of World
Standard Teletext (WST) as well as DVB Subtitles. In the case of
internet media and players, there were also a number of existing
distribution formats and players, such as SAMI (Microsoft - Windows
Media Player), QuickText (Apple - QuickTime Player), RealText (Real
Networks - Real Player), 3GPP TimedText, and so on.

[GA] Given these existing deployed formats and players, the TT WG asked:
"what problem are we trying to solve: are we trying to define a new
format and UA that will supplant (or compete with) the existing
distribution formats and players or are we trying to enable common
authoring and interchange among these existing formats?" The answer that
was agreed to by consensus was the latter (at least for the initial
focus of the technical work of the group): we need to create a common
interchange format that facilitates, at first order, a common authoring
system and transcoding to (but not necessarily from) the existing
distribution formats.

[GA] As a result of this decision, we began using the phrase "Timed Text
Authoring Format" (TT AF) to describe our work. It was around this
concept that we developed use cases and requirements, published at [1].

[1] http://www.w3.org/TR/2003/WD-tt-af-1-0-req-20030915/

[GA] As we began the work of developing a specification to satisfy these
requirements, we realized that there were two sets of needs that had
different priorities and different complexities:

(1) a solution that addressed the general authoring interchange problem
and that provided a high level of abstraction and separation of content,
style, layout, timing, and metadata, as well as
content/style/layout/timing alternatives;

(2) a solution that addressed the more pressing and less complex need of
interchange among a small number of legacy distribbution formats,
specifically SAMI, QuickText, RealText, 3GPP TT, CEA-608/708, and WST.

We then began to partition our solution space according to these two
problem sets and called the former AFXP (Authoring Format Exchange
Profile) and the latter DFXP (Distribution Format Exchange Profile).

We decided that DFXP should be a proper subset of AFXP and should
satisfy a number of features that would not be required of the former:

* streamability
* progressive encodability andd decodability
* self-containment (no resolution of external entities)
* constained decoding buffer size

Our model for DFXP was that it should (1) provide a framework for
interchange among the above cited simple distribution formats and (2)
not preclude direct use as a new streamable distribution format.

At the same time, the TT WG determined that:

(A) we would not actually define DFXP as a distribution format, but
merely define it as a potentially distributable format, i.e., we would
define distributability features;

(B) we would not actually define DFXP as a streaming format, but merely
define it as a potentally streamable format, i.e., we would define
streamability features;

The rationale and the consequence of these two determinations are as
follows:

In the case of (A), we could focus exclusively on defining content
syntax and authorial intentionality semantics, but avoid defining a UA
model and its consequent behavioral model.

In the case of (B), we could focus on defining features that enable
streaming (streamability features), but avoid defining a concrete
streaming representation and buffer model.

Now, the fact that the group has chosen to prioritize its work in this
fashion does not preclude the TTWG or another group defining -- in the
future -- a UA model and/or a streaming format/model.

This de-emphasis on defining a UA is also connected to two other points:

* the existing legacy formats described above already have UAs defined
in terms of those legacy distribution formats;

* for direct distribution of DFXP, such as in the context of a SMIL
presentation, the TTWG views DFXP as a media object, like a video or
audio object, which may be presented in a larger user agent context,
such as a SMIL UA; since we don't want to say how a SMIL UA should
operate, we viewed it out of scope to define a DFXP UA, even in this
case of direct distribution;

Lastly, I would like to refer readers to the system model described in
Section 1.1 of [2]

[2] http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050321/

As you can see from Figure 1, no User Agent appears in the System Model.
Each output of the model is designated as one of the following: (1)
input to an authoring system, (2) input to a transcoding system, (3)
input to a legacy format transcoder, or (4) input to some distribution
system for direct distribution.

The last of these outputs, as direct distribution, is not specifically
associated with any subsequent processor; rather, it is assumed that
this output connects to an arbitrary process that conforms with section
3.2, Processor Conformance, which, among other possible processing,
refers to a presentation processor. The semantics associated with such a
presentation processor are the closest DFXP comes to defining UA
behavior, and it tries to do so in a way that maximizes potential
presentation applications.

[While reviewing this and writing the above, it occurs to me that it may
be useful to add an external box called "DFXP Processor" and connect the
output labeled "Direct Distribution" to this box.] 
 
> >> For accessibility purposes it is helpful to have something like the
> > CSS2
> >> Cascade rules (which represented a change from CSS1 for enhanced
> >> accessibility). It turns out that text is about the only area where
it
> >> is easy for user styles to make sense, so it seems a shame that
there
> is
> >> no mechanism anticipated by the spec for using CSS and takng
advantage
> >> of
> >> the cascading of rules that are important to the user, where
> >> appropriate.
> >
> > In general, the WG has tried assiduously to avoid defining UA
behavior.
> 
> In this case I think it is a mistake. There are some cases where it
makes
> sense to describe what User Agents MUST, SHOULD and MAY do, and this
case
> might be one of them (since otherwise it maynoteven get onto the radar
> ofmany developers, leading to a serious lack of accessibility in
> practice).

See my above explanation for an attempt to describe the current
rationale for avoiding defining UA behavior.
 
I think the TT WG would be open to defining standard features in DFXP
that enable important processing functionality that is found in a UA
processing context, provided that such features do not make it difficult
or impossible to achieve the primary features I listed above
(streamability, self-containment, etc.).

I would note that the current DFXP spec supports arbitrary use of
elements and attributes in other namespaces, supports arbitrary metadata
scoped to most every element type; further, work on AFXP is proceeding
and will address certain concerns I have heard expressed, such as
content alternatives (content selection), styling/layout alternatives,
temporal (timing) alternatives, etc.

I hope this has helped explain some of the history of how the TTWG
arrived at its current location. Finally, the WG will respond formally
to your comments by separate communication.

Regards,
Glenn

Received on Saturday, 2 April 2005 13:13:43 UTC