- From: Glenn A. Adams <gadams@xfsi.com>
- Date: Mon, 21 Mar 2005 08:09:08 -0500
- To: <Johnb@screen.subtitling.com>, <shayes@microsoft.com>
- Cc: <public-tt@w3.org>
- Message-ID: <7249D02C4D2DFD4D80F2E040E8CAF37C0E9054@longxuyen.xfsi.com>
See inline below.
_____
From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com]
Sent: Monday, March 21, 2005 5:27 AM
To: Glenn A. Adams; shayes@microsoft.com
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange
Profile (DFXP) Streaming
Glenn,
Can you explain why you feel these properties are important to support
streaming?
"can be progressively encoded (i.e., does not require computing
subsequent data prior to sending current data);"
Surely this is just an encoder issue... An encoder can be assumed to
have the entire document available?
[GA] No. Not in general, e.g., a real-time feed.
This property may be a pre-requisite for forwarding (or transcoding) a
DFXP document.
"does not require dereferencing (and subsequent loading) of any
resources other than DFXP content (i.e., no embedded URIs);"
Is this just a timeliness issue?
[GA] No. Having to load any other resource may preclude direct streaming
through inline insertion, otherwise, any referenced resources would have
to be inlined and made availabe contemporaneously.
Loading of a resource (referred to for example by a header section)
would presumably just delay the ability to decode subsequent timed
fragments. A stream decoder may then incur a 'one off' setup period
where referenced resources were dereferenced and loaded. Any timed
fragment in a streaming scenario would need to be sent some (short) time
in advance of its activation period(s) on the timebase.
"does not support alternative content forms (e.g., different language,
graphics formats, time bases) in a single document;"
Why would alternate content affect streaming if it was inline in the
stream/fragment?
[GA] It doesn't affect streamability per se, but does affect utility of
bit transmission; e.g., sending bits that will or may not be selected is
a waste of potentially precious bandwidth in certain transport
environments. Also, it affects buffering requirements, as one is
potentially forced to buffer the content of both (all) alternatives
before making determination of what to keep and what to throw away.
The main reason for this constraint has to do with keeping DFXP simple,
or at least simpler, than AFXP (where it is expected that alternative
content will be supported).
I can appreciate that an alternate timebase **may** impact the temporal
order of fragments - and thus the stream transmission sequence.
"constrains content models to prevent arbitrary nested content
structures;"
As a complexity constraint or for some other reason?
[GA] Complexity and buffering.
regards John B
-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 19 March 2005 11:47
To: Johnb@screen.subtitling.com; shayes@microsoft.com
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format
Exchange Pr ofile (DFXP)
See http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050314/#streaming
for a prelimiinary discussion of streaming DFXP content, where data
access units are XML or infoset fragments of a DFXP document instance.
G.
_____
From: Johnb@screen.subtitling.com
[mailto:Johnb@screen.subtitling.com]
Sent: Friday, March 18, 2005 6:16 AM
To: shayes@microsoft.com
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format
Exchange Pr ofile (DFXP)
Sean,
Welcome aboard the thread!
[SH]
I've never really accepted that streaming a single XML document
is a particularly likely scenario. Much more likely IMO is to break the
captions up into 'I-frame' mini documents which stretch for a
significant period of time (e.g. a DVD chapter) and if necessary repeat
these on a cyclic basis in a media stream.
[JB]
An interesting idea.... I've only thought about this from each
extreme, i.e. streaming per subtitle (and periodically sending a
header), or sending the whole document. If I understand correctly you
are suggesting chopping a large DFXP document into multiple smaller
ones? Each valid in itself? This is certainly compatible with Digital
Cinema thinking, where a very large media file is chopped into 'reels'.
[SH]
I think it is likely that if and when AFXP is made available
that it, or more likely a constrained use of it (effectively another
profile), will be more useful as a modern captioning and subtitle
technology.
[JB]
Yes, I absolutely agree. Problem is the pressure is on to adopt
something now!. Maybe the 'path' is to adopt DFXP on the understanding
of allowing a constrained superset of DFXP (or AFXP sub-profile) in the
future, to cater for re-work scenarios.
best regards
John Birch
-----Original Message-----
From: Sean Hayes [mailto:shayes@microsoft.com]
Sent: 18 March 2005 10:30
To: Glenn A. Adams; Johnb@screen.subtitling.com;
public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format
Exchange Pr ofile (DFXP)
I'm just catching up on this thread. I must admit that I
share John's opinion that not supporting applicative styling in DFXP is
probably an error, and I have said so on numerous occasions in the WG,
however I have given in to the majority opinion (on the understanding
that this feature goes into AFXP). I do accept it would mean a
significant increase in overhead for DFXP, but in my opinion not so much
that makes it impractical.
What is probably more significant at this stage is that
adding it will delay the already well overdue DFXP document.
I've never really accepted that streaming a single XML
document is a particularly likely scenario. Much more likely IMO is to
break the captions up into 'I-frame' mini documents which stretch for a
significant period of time (e.g. a DVD chapter) and if necessary repeat
these on a cyclic basis in a media stream.
I think it is likely that if and when AFXP is made
available that it, or more likely a constrained use of it (effectively
another profile), will be more useful as a modern captioning and
subtitle technology.
Sean
_____
From: public-tt-request@w3.org
[mailto:public-tt-request@w3.org] On Behalf Of Glenn A. Adams
Sent: 17 March 2005 09:56
To: Johnb@screen.subtitling.com; public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution
Format Exchange Pr ofile (DFXP)
_____
From: Johnb@screen.subtitling.com
[mailto:Johnb@screen.subtitling.com]
Sent: Thursday, March 17, 2005 12:33 PM
To: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution
Format Exchange Pr ofile (DFXP)
Glenn,
Comments inline
-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 17 March 2005 16:11
To: Johnb@screen.subtitling.com;
public-tt@w3.org
Subject: RE: Timed Text Authoring Format -
Distribution Format Exchange Pr ofile (DFXP)
_____
From: Johnb@screen.subtitling.com
[mailto:Johnb@screen.subtitling.com]
Sent: Thursday, March 17, 2005 9:53 AM
To: public-tt@w3.org
Subject: RE: Timed Text Authoring Format -
Distribution Format Exchange Pr ofile (DFXP)
Glenn,
As defined, the use of referential styles
already requires head fragments to be repeated throughout a stream
transmission to permit mid-stream acquistition. A stream unit is not
directly parsable if it uses referential styling, because it will
require lookup in this 'head' fragment.
So it would seem that the sole reason for not
including class based (or rule based) styling is the need for
"re-evaluating all rules for each content unit that arrives".
[GA] Repeating a fragment that contains <head/>
or <styling/> is expected in a streaming delivery scenario. This would
be required in general in order to interpret any fragment that has a
semantic dependency on <head/> or <tt/>.
Exactly, and that is true for referential
styling too!
[GA] Yes. This is understood, and is acceptable
(and different from the general model).
Another, and more primary reason for not
including rule based styling in DFXP is that the WG made a conscious
choice to simplify DFXP, particularly since the expected mechanism to be
used for applicative styling will be the use of XPath expressions to
select the content to which styles will apply. The use of XPath
necessitates, in the general case, that the entire document is memory
resident in order to construct complex predicates.
Obviously a decision was taken by the WG, my
point is whether it was the correct one ;-)
I understand the restriction created by the use
of XPath, and also see the greatly increased complexity its use will
allow in document instances. It is unlikely that practical inserters
will be developed IMHO to process AFXP to true on-the-wire distribution
format - this is what DFXP was intended for. For my marketplace AFXP is
of little relevance, the workstation product will always be custom to
the role of subtitling - I see little to be gained by adopting the
extreme sophistication allowed by AFXP in a preparation workstation,
only to throw most of it away in the transition to DFXP. My interest is
in a distribution format that solves some of the interchange problems
that are faced now by the marketplace. If DFXP does not contain features
that provide improvement over existing formats, what will prompt it's
adoption over those formats? If you are suggesting that distribution be
performed using AFXP (or a sub-profile of it), for what is currently the
largest single target for DFXP (subtitling), then what future is there
for DFXP?
[GA] Clearly, the WG members believe that DFXP
is more than adequate to serve as an interchange format among existing
distribution formats. If you can present a concrete case why this is not
true, then I'm certain the WG will carefully consider. Also, keep in
mind that you can use arbitrary extensions in DFXP provided they are in
a different namespace. This will allow you and others to customize their
uses. If it appears that there is a common extension desired by many
parties, then we can consider standardization.
The WG rejected the use of a non-general,
special case mode of application such as you suggest, preferring instead
to support a general approach in AFXP.
I don't see rule based styling as non-general or
special case - it's a powerful feature of CSS.
[GA] And it will be similarly powerful in AFXP,
but not DFXP.
I am not personally convinced that this is more
onerous than supporting a referential style... YMMV !
Speaking as an implementor, I can assure you
that it is more simple to implement referential styling.
Hmmm! I was also speaking as a potential
implementor. Why do you think searching for an applicable rule is more
difficult than searching for an applicable style reference?
[GA] Because looking up a referential style does
not require traversing the document instance. It merely requires a
hashtable lookup on the set of styles already received in the fragment
that contains the <styling/> element. In contrast, applicative styling
potentially requires evaluating every node of the DOM in order to match
a single rule.
Not including this feature in DFXP does make
restyling of DFXP content somewhat more onerous.... since any
relationship between a role and a style will be lost by transition into
DFXP. Consequently, this mandates the use of AFXP for exchange and
pre-distribution storage if the intention is to support these relatively
minor 'presentation' changes at output time.
If you examine the TTAF System Model in Figure
1, you will see there is a compilation step when going from general AFXP
to DFXP. Compilation usually involves a loss of abstraction, in order to
construct a simpler equivalent expression. This is the model followed
with DFXP.
Yet this is more than a loss of abstraction, it
is a real loss of data. The relationship between the style and the
metadata is lost.
[GA] What you call "data" I call "abstraction".
It does not lose "content". Furthermore, if a compiler wishes to do so,
it can add non-standardized decorations that allows it to recover the
abstraction. However, standardization of such reversible transform is
not a requirement for DFXP, and, indeed, was an explicit
non-requirement.
I may seem to be 'pedantic' on this point, but
one of the major limitations of existing formats is that they do not
support easy transitions between real on the wire distribution formats -
where the distribution formats do not provide equivalent support for
presentation options - simply because they also do not convey this
connection between style and role. If there is no connection between the
role / agent metadata and the style in DFXP - then there is little point
in including the role and agent metadata IMHO.
There is no normative use of role/agent in DFXP;
it was included to permit passing through this metadata from AFXP for
use by non-standardized processing, or potentially future standardize
processing. An AFXP to DFXP compiler is free to not include this
metadata in DFXP. However, it is there in order to permit an author to
interchange it on an end-to-end basis.
Yes, I understand. But exchange between
**authors** should be at an AFXP level surely?
[GA] It is not the intent of the WG or its specs
to dictate to authors how they should use the different profiles. It is
their choice. The two profiles have different design centers. DFXP is
explicitly intended to be cooked/flattened/compiled...
DFXP is targeted to support conversion into
multiple true distribution output formats. This one to many relationship
requires that the one format (the source) contains a sufficient
richness, or a sufficiently high level of abstraction to support the
variations in output formats, but still retain the original intention of
the author.
[GA] Then you will want to use AFXP for such
abstraction level, or add proprietary extensions to DFXP.
The intention of the author (in subtitling at
least) is NOT that a particular word be red, or italicised, but that it
be different from the surrounding context. Or put another way, what is
important is not **THAT** the style exists, but **WHY** the style change
exists. Further, there are very fixed conventions as to the styling used
to represent different contexts (dialogue, shouting, sound effects,
music), and those conventions differ from true on-the-wire distribution
format to format - and from user to user! But these conventions exist
for the same purpose, regardless of distribution format, and it is that
**purpose** that needs to be preserved (and IMHO enforced) in DFXP.
[GA] I'm afraid you have a different idea of the
intention of DFXP than the TT WG. The intention you ascribe to DFXP is
what the TT WG ascribes to AFXP.
My concern Glenn is this.
Once you make the context optional, you
effectively have thrown it away. Without a strong emphasis on the
relationship between style and 'role', DFXP seems to be heading in a
direction that (almost) encourages the development of 'cooked'
documents. IMHO this is the antithesis of what is required in a true
multi-target distribution format. I would personally dare to suggest
that DFXP should drop inline style and style references **totally**, in
favour of ONLY a class based style mechanism - simply to enforce the
relationship between style and context/role.
This is because in order to support the
conversions that would be anticipated, the style mechanism would have to
also carry the role aspect as part of the style ID.... thus creating an
explosion in style definitions. Further, each fragment of content that
required identification would need to carry a style reference.
Summary.
IMHO In this aspect, DFXP is too cooked. I
prefer mine raw!
Then please contribute and support the
development of AFXP.
I intend to, but I'm not so interested as to
fund joining the W3C out of my own pocket ;-)
[GA] Then you will have to be satisfied with
what the TT WG produces, while, of course, taking due consideration of
yours and other comments from the public. I would note that some very
small companies (mine for instance) is willing to make this investment
out of pocket.
BTW - Where does this streaming issue come from,
a DFXP file is likely to be trivial in size compared to ANY companion
stream. (e.g. video or audio). I would suggest that any composite stream
that included a TT content stream would simply do so by reference and
require the target to pull down the entire file.
[GA] There are many real-world use cases where
it would be useful or important to integrate DFXP content into a
streaming data context, particularly in unidirectional delivery
contexts.
regards John Birch.
-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 17 March 2005 14:02
To: Johnb@screen.subtitling.com;
public-tt@w3.org
Subject: RE: Timed Text Authoring Format -
Distribution Format Exchange Pr ofile (DFXP)
Actually, DFXP does not support
out-of-line styling in the traditional sense (e.g., CSS sense). The fact
that one can place style specifications in <head/> and share their use
among multiple content elements is merely an optimization of expressing
inline styles (by reference). We call this referential styling.
What you are requesting is a form of
rule based applicative styling that applies independent style rules to
content based on matching criteria. This mechanism will be defined in
AFXP, but was explicitly ruled out for DFXP since it requires either (1)
having all content available to apply rules to, or (2) repeatedly
re-evaluating all rules for each content unit that arrives (e.g., in a
streaming scenario).
The basic model for DFXP is completely
inlined styles, but the referential styles were defined as an
optimization to allow:
(1) aggregation and sharing of
common inline styles
(2) pre-delivery or separate
packaging of a fragment containing referential styles from fragments
containing content
The decision to simplify DFXP was based
on the desire that DFXP content be more concrete and directly
parsable/renderable in a potential streaming context. The general use of
out-of-line applicative style rules is antithetical to this approach.
G.
_____
From: Johnb@screen.subtitling.com
[mailto:Johnb@screen.subtitling.com]
Sent: Thursday, March 17, 2005 7:56 AM
To: public-tt@w3.org
Subject: RE: Timed Text Authoring Format
- Distribution Format Exchange Pr ofile (DFXP)
Glenn, et al,
The DXFP specification includes support
for styling, both in-line and out-of-line styling.
However it does not support a class
based styling model.
In subtitling, styles are most often
associated with changes in the text 'role' (e.g. dialogue differs in
presentation from music) or 'speaker' (Joe - red, Frank - blue).
Could a mechanism be added to support
this?
E.g. This might be represented in DXFP
by utilising a class based style mechanism that was sensitive to
ttm:role and ttm:agent. Thus:
<style id="s1" style tts:color="white"
tts:fontFamily="monospace-serif"/>
<style id="intro" style="s1"
tts:fontSize="4%"/>
<style id="documentary" style="s1"
tts:fontSize="10%" tts:fontFamily="sans-serif"/>
<style id="music" ttm:role="music"
tts:fontStyle="oblique"/>
<style id="joe" ttm:agent="joe"
tts:color="red"/>
<div style="intro">
<!-- all text 4% high -->
<!-- all text monospace-serif -->
<p ttm:role="music">Quiet Violin
music</p>
</div>
<div style="documentary">
<!-- all text 5% high -->
<!-- all text sans-serif -->
<p>White Large sans-serif</p>
<p ttm:role="music">White Oblique Large
sans-serif</p>
<p ttm:agent="joe">Red Large
sans-serif</p>
</div>
the ttm:role and ttm:agent attributes
could be considered as implicitly adding inline style attribute(s) to
their container....
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.
-----Original Message-----
From: Glenn A. Adams
[mailto:gadams@xfsi.com]
Sent: 14 March 2005 16:51
To: public-tt@w3.org
Subject: Timed Text Authoring Format -
Distribution Format Exchange
Profile (DFXP)
A new update of the Timed Text Authoring
Format 1.0 - Distribution
Format Exchange Profile (DFXP), is now
available at [1]:
http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050314/
The TT WG solicits your comments on this
new draft as soon as possible,
as a very rapid turn-around is expected
in order to publish a first Last
Call (LC) draft.
Please sent comments either to this list
or, if you prefer privacy, to
me directly.
Regards,
Glenn Adams
Received on Monday, 21 March 2005 13:58:06 UTC