RE: TT and subtitling/captioning - separating timing from style f rom content

Thank you for the thoughtful response.  There's a lot of agreement, 
here.  A few
clarifications inline below.

At 11:54 AM 2003-08-07, Johnb@screen.subtitling.com wrote:

>Al,
>
> >> Assuming that I wish to separate the timing in my TT-AF
> >> document from the content by using references within the timing 'tree' 
> a la Daisy
> >> model - and assuming that this might be possible!
> >> - would it then possible to apply style through the timing tree rather
> >> than by inline markup or attribute within the text content.
>
> > If you are happy to use a SMIL wrapper to sequence and time
> > the presentation,
> > you can use the digital talking book specification and you
> > don't need TT-AF
> > which will be a more lightweight specification for marking
> > the timing in the
> > file with the text content, IIRC.
>
>Hmmm... Not sure about using SMIL I'm unconvinced that it's a good fit 
>with what I would use TT-AF for.
>For one thing the timing model in SMIL doesn't suit external timing - the 
>synchronisation model is primarily
>internal (if you get what I mean). Happier to use limited SMIL semantics 
>though..... why re-invent tag names :-)
>
>I will read the DTB spec again - it's close to what I want to do... but a 
>bit of a tangent from my requirements IIRC.

Absolutely.  Most of what they have you don't need.  But most of what you need
has a precedent in there somewhere.  [And some of what they have you may 
need and
not have articulated the need yet.]

> > Secondly, the best practice is not to apply the style inline
> > in the timing script, but it would be natural to associate a stylesheet
> > cascade with each channel or display region.
> > But you still want to put a well-articulated
> > display-mode-independent basis for the styling in the markup
> > of the text itself.
>
>I certainly agree that referencing external stylesheets is preferable,
>but what I don't want is to put the reference to the style in the content.
>The reason I don't want to do this is because the style desired for the 
>content
>will need to vary depending upon which of multiple timelines is being played.

Yes.  This is one of my major points.  And I don't think that either SMIL
or HTML give us a precedent we can 'just use' and meet the needs of the
future world where multimodal interaction and device-independent authoring
are intrinsic in the web technology.

string-search for "session 2" in
  Agenda: W3C Technical Plenary, 5 March 2003
  http://www.w3.org/2003/03/TechPlenAgenda.html

Among the variations in 'delivery context' that are used by people with
disabilities there are variations in the pagination/chunking and
pull-vs.-push balance in the dialog.  I see this as a re-engineering
requirement because the precedent in HTML is for the content document to
cite its proper stylesheets, whereas the correct decision flow is that the
style policy is decided based on the content and delivery context, jointly.
The content document should cite the rhetorical ontology used in classifying
the content, not the style policy repertory appropriate for presenting the
content.

In tactical terms it could mean that there are pure and adapted forms of the
content in the process flow.  An XSL transform that inserts the style refs
appropriate to the delivery context of the moment.  But it is clear that
the content maintenance form is the pure.

>The timelines are in effect the description of how the content is
>presented temporally for a specific display. Specific displays have 
>limitations that
>prevent the adequate representation of certain styles, limitations on line 
>lengths and line breaking etc.

The display and the user enter into the decision as to which timing should
be used.  In the long run we may be able to get the user's need articulated
and uploaded for server satisfaction.  But in the mean time the user may be
browsing options and interactively selecting an option that works for them.

The Device Independence authoring discussions have been good in terms of
factoring the enumeration of the _presentation decisions to be made_, the
_delivery context factors affecting the decisions_ and the _content factors
affecting the decisions_ into three spaces that then get composed in the final
analysis.

>I'm also not really angling after the issue of user defined style sheets - 
>I don't think that is particularly
>relevant in an **authoring format**.

Saying that will earn you the undying opposition of the accessibility 
community.
[emphasis often cues that subliminally you understand that you have a weak 
position...]

The "authoring format" must accept as a prior and external constraint that it
composes well with post-authoring changes in styling decisions.  Compare with
the W3C Recommendation known as

  User Agent Accessibility Guidelines 1.0
  http://www.w3.org/TR/UAAG10/

in particular

  1.6 User control
  http://www.w3.org/TR/UAAG10/intro.html#user-control

  4. Ensure user control of rendering
  http://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-styles

Even 'though 80% of the use of the TT-AF may be to drive delivery contexts
such as analog TV where the user's entire control over the caption pane is a
boolean 'present/absent' control, the format must be architected for a
universe of modes of use which include user-directed re-styling of the
content which has been captured in the authoring format.

The decision flow is roughly that the User Agent gives the upper hand initially
to the author in setting style decisions, but in the end to the user.  We 
talked
this through to a mutually-tolerable detente with the SMIL group concerning the
'override' attribute.

some WAI comments on Device Independence
  http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html

Al

> > Why does the text have hard line breaks?  Typical cases are lists and 
> poems.
>The line breaks were in the example I snipped from a GA post and were not 
>intended
>to imply any behaviour other than differentiating the two pieces of text.
>Please ignore them and just consider it as 'text line one' and 'second 
>line of text'
>
> > CSS provides facilities to apply styles by ID-keyed selctors but this is
> > should be avoided.
>
>Why?

Because it gives zero information for the creator of an alternate style, and
because it is a missed opportunity to create a reusable style rule.

A unique styling is still usually rationalizable based on a unique
conjunction of content factors and delivery context factors.  The problem is
that articulating the underlying factors is a knowledge engineering task
that takes getting "out of one's box" which in practice takes a second set
of eyes -- passing the work by another person.  That doesn't come free.
There have to be Enterprise Integration payoffs to make this level of
rationality affordable, but in business contexts the EI payoffs are
generally lurking in the situation.

> > Then encode the basis for the styling decisions in
> > [elements and attributes in] the content markup, and key the
> > result to the encoded basis by the selector in your separate style rule.
> > This will give you a rule you can lift and reuse.
>
>But content markup is messy - content and style are two faces of the 
>(three sided :-) TT coin.
>
>It's not always appropriate to have style inside content - not if you want 
>to reuse the content in different contexts.

Content modeling is difficult.  So it may seem messy.  But the correct
factorization into style vs. content includes more in the 'content' than
what people will at first recognize as their content.  The difference can be
roughly described as articulating the rhetorical roles of sub-parts of the
content.  It takes some push-back, extra effort, to get the content fully
articulated with rhetorical-role properties in place.

What I am saying should be articulated as _content_ aspects or properties is
not the style including indents and fonts.

But the basis for the style, such as: class="new featured"

  class use - innovations only, pls.
   http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/0491.html

Then in the stylesheet one selects the domain of a style rule by articulated
content features.

The point is that where there are variations in the styling, there is an
underlying rhetorical shift.  Get the rhetorical shift and the content model
supports multiple adapted views, not just the one that you envisioned.  If only
one presentation is worked through to completion, the factorization into 
content
and style is generally a failure.

>It's a triumvarate
>
>Style + Content + Timing. Ideally none should be intermixed with the other.

An ideal that breaks down on close examination, but still a direction to try
to move in.  Actually the reality is that there is presentation which if we
are lucky is factored reasonably well into some sort of resource base and
[one or more] presentation transform[s].  Until there are actually multiple
views in play and checked in the authoring, it is a fiction anyway.
Consider the mso practice of using style names as class tokens.  This is not
the accessible practice.

But timing couples with chunking couples with [in interactive spaces]
navigation couples with styling.  So the schema for the 'content' model
has to be iterated on until successful multi-view presentation is reliably
achieved.  What I am talking about are the pre-style content properties
that are a sufficient basis to key the selection of appropriate styles
in different presentation spaces from a caption window to a voice browser
dialog.

The architecture of the future web, particularly for authoring, is an
architecture for authoring the content model that supports extraction in
multiple views, a model that is appropriate to multiple delivery contexts.

  WWW2003 DevDay Track6 presentations (all)
   http://lists.w3.org/Archives/Public/www-archive/2003Jun/0036.html

Al

>Note: Ive spooled the temporal flow off into a separate response to Glenns 
>recent post....
>
>regards
>John Birch
>
>The views and opinions expressed are the author's own and do not necessarily
>reflect the views and opinions of Screen Subtitling Systems Limited.

Received on Friday, 8 August 2003 11:11:05 UTC