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