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.