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/>.

 

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.

 

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 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.

 

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.

 

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.

 

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.

 

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