RE: XSL and CSS Re: Coments - last call draft

Glenn,

OK, I'll try and frame what I see as the style problem....

The DFXP style model is quite suitable for the carriage of styled text, BUT,
in the contexts of accessibilty and transcoding, the DFXP style mechanism
IMO lacks an essential ingredient, that being the reason for (or context of)
the applied style.

As an example - an author may choose yellow text on a red background for a
warning message.

The carriage of that text as simply text characters and colour codes loses
one piece of information - the fact that it was intended as a warning.

This missing information becomes important when interchanging content
between formats that have different support for style (for example between a
colour and monochromatic presentation), or in transcoding / translating
content between cultural groups.

Another example - Green is 'lucky' in Ireland, but Red is 'lucky' in China.
Go n'éirí an t-ádh leat could translate to ??? (Note: Internet machine
translation!).


 
You have stated that it is possible (likely) that this style tagging
(context) will be a feature of AFXP and that DFXP is a format intended as "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." 
 
It should be noted that CEA-608/708, and WST (and in fact TV subtitling
formats in general) are typically not stored in these wire formats by
broadcasters, rather these wire distribution formats are created in
real-time by insertion equipment working from proprietary file formats. A
single common file format already exists as a ratified interchange standard,
EBU 3264. DFXP could replace the use of EBU 3264 - it offers a few of
advantages, a) it is Unicode, b) it is XML and c) it has a more
comprehensive language tagging mechanism. However, DFXP does not offer any
significant new features over EBU 3264, and indeed there are features in
EBU3264 that are not present in DFXP (e.g. cumulative mode and boxing). 
A combination of extension elements and attributes and constrained document
structuring (via a sub-profile) can probably be used with DFXP to fully
represent EBU 3264 document contents - and other general TV broadcast
related subtitling issues. Indeed, it is anticipated that the use of DFXP as
an interchange mechanism for TV broadcast subtitling will require the
development of guidelines for the interpretation of DFXP documents by
transcoders. In addition it will probably require the development of a
profile to add elements and attributes to DFXP to carry information and
features currently supported by existing formats, (e.g. conditional content,
cumulative modes, background styles, embedded glyphs, subtitles as images
(DVD, DVB, Imitext)).
 
The pressing need is not IMO for another interchange format per se, rather
it is for a format that preserves more of the authorial intent (inc.
understanding / meaning) such that implementing transcoding, translation and
accessibility are made easier tasks than they are currently. My main
concerns are that using DFXP will encourage the continuation of the existing
practice of 'cooked text content' - that is text that has lost contextual
meaning - and that AFXP will be too complex and too late for most
implementations.
 
Is there a middle path for DFXP that would encourage a more context
sensitive (and accessible) role for text style? DFXP already includes a
referenced style mechanism - could that mechanism be strengthened to provide
greater support for contextual styling of text?
 
best regards 
John Birch.

-----Original Message-----
From: Glenn A. Adams [ mailto:gadams@xfsi.com <mailto:gadams@xfsi.com> ]
Sent: 03 April 2005 18:57
To: Charles McCathieNevile; Al Gilman; public-tt@w3.org
Subject: RE: XSL and CSS Re: Coments - last call draft



I will make sure the TT WG considers your proposal, however, I will be
surprised if there is sufficient support to do so, particularly since
DFXP does definie style and layout information already (based on XSL,
which the TTWG deems sufficient), and since DFXP does not define a UA
nor does its processing model presuppose a UA.

Rather than focusing on a preferred solution (that you seem to be
proposing), let's try to focus on the problem and the requirements to
see whether we really have a problem here. I'm not sure the problem is
being framed well here.

Regards,
Glenn

> -----Original Message-----
> From: Charles McCathieNevile [ mailto:charles@sidar.org
<mailto:charles@sidar.org> ]
> Sent: Sunday, April 03, 2005 1:17 AM
> To: Al Gilman; public-tt@w3.org
> Subject: XSL and CSS Re: Coments - last call draft
>
>
> On Sat, 02 Apr 2005 00:06:17 +1000, Al Gilman
<Alfred.S.Gilman@ieee.org>
> 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.
>
> >  On the one hand, XSL FO does address accessibility through the
> > link-to-source provision.
>
> > http://www.w3.org/TR/xsl/slice7.html#common-accessibility-properties
<http://www.w3.org/TR/xsl/slice7.html#common-accessibility-properties> 
>
> This is for XSL FO documents - not for a different collection that
happens
> to use some of the properties out of XSL-FO. A link to the source
where it
> issome other format isn't likelyto beay more helpful than the DFXP
> document.
>
> >  If DXFP does not emulate this, it should be considered.
>
> >  On the other hand, CSS already arogates to itself the ability to
> > supercede presentation properties asserted inline in the source
being
> > styled.
>
> Right. My contention is that DFXP should use CSS as the mechanism by
whch
> User Agents provide users with the ability to override presentation,
where
> that is required for accessibility reasons in the case that DFXP is
served
> directly.
>
> cheers
>
> Chaals
>
> --
> Charles McCathieNevile                      Fundacion Sidar
> charles@sidar.org   +61 409 134 136    http://www.sidar.org
<http://www.sidar.org>