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

See inline below.

 

  _____  

From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] 
Sent: Monday, April 04, 2005 7:35 AM
To: Glenn A. Adams
Cc: charles@sidar.org; Alfred.S.Gilman@IEEE.org; public-tt@w3.org
Subject: 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.



[GA] It is trivial to include arbitrary user-defined metadata in DFXP. One can also use user-defined values for the ttm:role attribute. In both cases, you have a means to express and interchange additional intentionality. It is far from clear what additional standardization in this area may be warranted in DFXP at this time.

I would also note that you can use a naming convention in DFXP to express context, e.g.,

<style id=”warning” tts:color=”red”/>
...
<span style=”warning”>Don’t Panic!</span>

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." 

 

[GA] I’m not sure what you mean by “style tagging (context)”, so I cannot say if it would be a feature or not. What is planned for AFXP is “applicative styling”, which allows using a “select” attribute on a style element or on a group of style element, where the value of “select” is an XPath expression that selects content elements to which  the styling is to be supplied. I’m not sure how this relates to your phrase “style tagging”.

 

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). 

 

[GA] I’m not sure what you mean by “cumulative mode” or “boxing”, so I can’t say whether these are supported in DFXP or not.

 

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?

 

[GA] You are asking to expand the scope of DFXP from its express role as a useful subset for interchange among existing legacy formats to a role approaching AFXP. In other words, you are effectively asking the TT WF to drop its work on a subset that could serve an immediate purpose and be a stepping stone to a more general solution. I can’t imagine the TT WG changing its course on this point, but we will discuss your comments and respond formally with a consensus position.

 

best regards 

John Birch.

-----Original Message-----
From: Glenn A. Adams [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]
> 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
>
> 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