RE: Coments - last call draft

Charles,

you wrote[31 March 2005 02:46]:

[[[
If not specified, the default length unit must be considered to be pixels.
]]]

For accessibility reasons, it seems better in a pure text format to use an 
element based on font size, such as the em unit, as a default. I realise 
this implies a small change in the practice of authors, who are probably 
generally accustomed to working in pixels. But then they are probably not 
generally accustomed to working on accessibility.

In general I support your view - but I would prefer that scalar values were
ONLY relative rather than absolute - such that all expressions of dimension
were always in terms of proportions of either the target canvas, or of a
selected font. The use of absolute scalar values creates files that are
tightly bound to a specific target display (which is hardly fitting for an
interchange mechanism). Moving to an em unit as a default could be
problematic, as sizing then becomes dependent on the font not the canvas
(thus when canvas size is fixed - overflow/clipping may occur).

frameRateMultiplier (et al)

Actually it seems strange that so much of this is in the spec. I 
understand that it enables synchronisation with traditional television, 
but it seems a lot of complexity.

Again I agree. I cannot see any benefit in having this complex a mechanism
(and I am looking at implementations that **wil**l require synchronisation
with traditional television!). 

IMO There are two timing models that might apply to TT, I'll call them,
intrinsic and extrinsic. In the intrinstic model, timing is self-timed and
internal (this only requires a single specified timebase e.g. milliseconds).
In the extrinsic model, timing is slaved to an external timebase. The
extrinsic model may require a definition of the external time source e.g.
clock or smpte. However, the extrinsic model does **not require** a
definition for the external time source representation, since it can be
safely assumed (and specified) that a document using extrinsic time
synchronisation will contain time values in the same format as the external
source, and **all** that is required is a match algorithm.... I.e.
10:00:01:23 matches 10:00:01:23 regardless of whether these are 30DF 30NDF
25PAL etc. The requirement for most of these timebase attributes only arises
by allowing 'dur' as an attribute, since this necessitates the calculation
of effective end values, which in term requires an understanding of
framecounting in different timebases.

It would be helpful if the spec said what happens when the begin/end and 
the dur attributes don't agree.

Or if it said that you can use begin + dur, and begin + end, but not begin +
end + dur! 

IMO - drop dur as an attribute - it can be equivalently expressed using
begin and end - and the above issues can then be simplified.

Quite a lot of work went into CSS. It is also considered pretty normal to 
style XML with CSS.

For accessibility purposes it is helpful to have something like the CSS2 
Cascade rules (which represented a change from CSS1 for enhanced 
accessibility). It turns out that text is about the only area where it is 
easy for user styles to make sense, so it seems a shame that there is no 
mechanism anticipated by the spec for using CSS and takng advantage of the 
cascading of rules that are important to the user, where appropriate.

No argument here! - but DFXP uses the XSL-FO model as a foundation not CSS.

regards

John Birch
Senior Software Engineer,
Screen Subtitling Systems Limited,
The Old Rectory, Claydon Church Lane,
Claydon, Ipswich, Suffolk.
IP6 OEQ

Tel: +44 1473 831700
Fax:+44 1473 830078
www.screen.subtitling.com

See us at NAB Las Vegas April 18-21st Stand No. SU8956

This message is intended only for the use of the person(s) ("the Intended
Recipient") to whom it is addressed. It may contain information which is
privileged and confidential within the meaning of the applicable law.
Accordingly any dissemination, distribution, copying or other use of this
message or any of its content by any person other than the Intended
Recipient may constitute a breach of civil or criminal law and is strictly
prohibited. If you are not the Intended Recipient please destroy this email
and contact the sender as soon as possible.

In messages of non-business nature, the views and opinions expressed are the
author's own and do not necessarily reflect the views and opinions of the
Screen Subtitling Systems Limited.

Whilst all efforts are made to safeguard Inbound and Outbound emails, we
cannot guarantee that attachments are Virus-free or compatible with your
systems and do not accept any liability in respect of viruses or computer
problems experienced.