RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming

I have some thoughts on the four points below: -
 
 
1) Progressive encoding is vital for any type of live subtitling.  The
alternative is to make every subtitle a complete document in its own right -
which would bump up the bandwidth requirements all round.
 
2) Loading of external resources may cause problems when the files are
introduced into real broadcasters networks - often protected by a firewall
and a tight access policy.  These things can be circumvented by pre-checking
before the content enters the protected zone but in these days of tight
timescales this could prove too restrictive.
 
3) I don't see a problem with allowing different languages in the same
document but amalgamating different language files at run time is not
difficult.
 
4) Unconstrained nesting can lead to run-time problems when resources run
out (stack overflow etc.)  If maximum nesting depth is not defined then it
cannot be tested for and thus may lead to surprise instability.
 
Regards - Russ Wood

-----Original Message-----
From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com]
Sent: 21 March 2005 10:12
To: gadams@xfsi.com; shayes@microsoft.com
Cc: public-tt@w3.org
Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr
ofile (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? 
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? 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? 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?
 
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
<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 <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/
<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 

 


________________________________________________________________________
This e-mail has been scanned for viruses by MessageLabs.




________________________________________________________________________
This e-mail has been scanned for viruses by MessageLabs.