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

It seems fairly clear that DFXP is not going to be useful for John, DFXP
was designed as a very specific subset of TT for a very specific purpose
and not necessarily as a 'stepping stone' to AFXP and thus I don't wish
to labor that point here, although I also would like more of the AFXP
features in DFXP. However if AFXP is not suitable for Johns requirements
then I think we have more of a problem.

 

The use of applicative style/timing however in AFXP does I believe
achieve exactly what I you are asking for.

 

In the scenario that you want warnings in your titles, you would
annotate them either using ttm:role='x-warning' (or an attribute in some
other namespace or elements in a <meta> block). Since AFXP styling uses
fairly general XPaths, you can then apply a style like so:

 

<style select="//*[@ttm:role='x-warning']", tts:background-color='red'
tts:color='yellow'.../>

 

With conditional inclusion of stylesheets, or conditions within
stylesheets, you can then make warnings market specific.

 

Similarly timing can be applied in exactly the same fashion, so that
content can appear (or not), move around etc. based on the attributes
you provide.

 

This mechanism is very flexible, general and fundamental to AFXP TT, and
not just a mechanism for hiding or reducing definitions.

 

________________________________

From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On
Behalf Of Johnb@screen.subtitling.com
Sent: 04 April 2005 10:09
To: gadams@xfsi.com
Cc: public-tt@w3.org; charles@sidar.org; Alfred.S.Gilman@IEEE.org
Subject: RE: XSL and CSS Re: Coments - last call draft

 

Glenn

See inline below.

	I wrote:

	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.

	[JB]The key words here are 'arbitrary' and 'user-defined',
rather than standardised (as in CEA 708 - 8.5.9 Caption Text Function
Tags). I had hoped that DFXP would include a formalisation of a text
context mechanism that could be associated with presentation. Note I am
not suggesting that it is in scope to define a fully inclusive set of
attribute values to define all possible text contexts (although some
could be included), but I do think it in scope to define a mechanism for
effectively associating arbitrarily complex contexts with text - the
namespace mechaism can handle the issue of defining the context.
Similarly a mechanism could also be formalised that allows the
association of context with style.

	 

	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>

	Here - the choice of id value is arbitrary, and could only be
restricted by convention. As such, this is contrary to my concept of a
universal interchange format.

	 

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

	Not at all I fear :-( This sounds like just an another mechanism
for hiding or reducing the number of style definitions......

	 

	Sorry - on reflection "style tagging (context)" is a rather
woolly phrase....

	 

	What I am suggesting is a means of associating a context with
text content, and also associating that context with styling - such that
users of the document can associate a style with the text content (be it
for transcoding/translation or for display), where the style is
defined/influenced by the context (hierarchy). So axes on the context
'graph' might include 'role' and 'emotion' and 'prosody'. Note I am not
specifically proposing a mechanism here - just trying to describe the
concept. You might suggest that these concepts have only a peripheral
role in timed text, I would suggest that they have an incredibly
valuable role in subtitling and accessibility. 

	 

	The 'rules' for associating context and style need not be
applicative in the way that CSS implements selection based styling, they
can create a pre-determined hierarchy in the head of the document. The
context of text content cannot change after authoring - so it is similar
to the DFXP referential style concept. What might change is the users
requirement for how text associated with that context is presented (or
indeed if it is). By including more support for context - you can
achieve a more acceptable presentation of the document to a wider
audience, for example the inclusion of 'prosody' information might allow
better (re-)speaking of the content. Inclusion of 'role' allows
filtering... and so on.

	 

	I guess I am disappointed that this is seen as optional - rather
than as fundamental to Timed Text in general.

	 

	It has been stated that:

	"The intent with DFXP is to have already made all conditional
selections prior to transmitting/exchanging in DFXP format."

	 

	This has important implications for TV subtitles. DFXP is
currently under consideration as a foundation for containing subtitles
within MXF / AAF media packages for use in TV and Digital Cinema. While
making selections prior to transmission or exchange is reasonable, it is
not so reasonable to make these selections prior to the storage of an
asset. This is because the circumstances affecting the selection may
change between the storage of the asset and its subsequent transmission.
In effect this DFXP constraint implies that using 'pure' DFXP as the
storage format would require that all possible outcomes of the selection
process be stored as separate DFXP files within the asset package - e.g.
a file for each language - plus a file for each conditional content
switch (e.g. caption/subtitle, pre-watershed/post watershed). This is
sub-optimal.

	Conditional content could be implemented using text context and
associated styling.

	 

	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.

	[JB]Cumulative mode rests upon the concept of a 'cursor
position' - such that subsequent text can be appended to text already in
view. DFXP can emulate the output of a cumulative subtitle file, but
does not necessarily capture the fact that fragments of text form a
complete subtitle (except indirectly by virtue of the fact that they
share a common end time). Conversion between a cumulative mode subtitle
file, and a non cumulative mode file represented by DFXP is thus made
more difficult - since the grouping of fragments is lost. You could
adopt a 'convention' where a <P> element always contains a complete
subtitle - but this is then mixing two concepts together, reducing the
usefulness of the <P> element. This is because conversion between
presentations that allow different numbers of displayed lines and
characters requires a distinction between logical text boundaries
(paragraphs) and the arbitrary boundaries imposed on the text by the
limitations of the subtitles mechanism. So conversion between 2 row line
21 captions and 3 row Teletext captions should use <p> as a logical
division in the text - when reformating 2 row subtitles into a 3 row
format.

	 

	Put another way - cumulative mode is a 'cooked' way of pacing
the display of text to the user.

	 

	Boxing is the issue of background colour only behind glyphs, not
for the whole region (see my earlier email (sent Wed 16/03/2005 17:36)
regarding extending the values for the show-background attribute).

	
	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.

	I fully understand the position of the TTWG, however, I have
strong reservations as to how effective DFXP is as a stepping stone to
AFXP - when DFXP essentially bypasses most of the 'harder' problems,
that I hope AFXP will address, and leaves no obvious placeholders for
them to fit into.

	 

	I don't want TTWG to drop the work on DFXP - far from it - but I
am uncertain as to the the larger role for a format that provides the
same level of functionality as the existing legacy formats - but
includes few features that support and extend the concept of universal
content.

	 

	I would be delighted however if DFXP showed a turn away from the
markedly 'cooked' approach it has (to style in particular). 

	IMO DFXP is currently in short - far too presentation centric. 

	DFXP would IMO be considerably more useful if it explicitly
provided more support for 'soft' styling of the text content (and
promoted the concept).

	 

	I believe that DFXP will be adequate to interchange the current
web based formats, and with some tweaks (by profile or convention or
both) will be able to interchange TV broadcast subtitle files. In that
respect DFXP has met its goals.

	 

	Finally - most of these concepts that I am alluding to are not
present in any existing legacy formats, I wish that they were. Subtitle
files formats typically are cooked - the text smashed into arbitrary
units (subtitles) with hard styling applied. It is my frustration at
dealing with the conversion of these files between systems/formats that
has prompted my 'crusade' for more abstraction within DFXP/AFXP. I guess
I am just disappointed that DFXP is unlikely to make these issues any
easier and concerned that standard (non-profiled) DFXP will perpetuate
the problem by becoming adopted as yet another cooked format.

	
	best regards
	John Birch.