- From: Glenn A. Adams <gadams@xfsi.com>
- Date: Tue, 29 Mar 2005 09:23:21 -0500
- To: <Johnb@screen.subtitling.com>
- Cc: <public-tt@w3.org>
- Message-ID: <7249D02C4D2DFD4D80F2E040E8CAF37C03C37B@longxuyen.xfsi.com>
Keep in mind that you can introduce non-standard attributes and elements in different namespaces, and you can ascribe these with semantics that meets your deployment needs. You can combine these with an XSLT/XQuery transform stage to achieve powerful and flexible mappings from your "archive" to your final delivery forms. Keep in mind also that DFXP is intended to be explicitly simpler than some of the features you seem to ask from it. Our original goal was to simply capture an essential intersection of the union of SAMI, RealText, QuickText, and 3GPP TT. I believe we have accomplished that plus some. We need to ensure that feature creep does not prevent us from establishing this important baseline upon which other profiles can be profitably constructed. G. _____ From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] Sent: Tuesday, March 29, 2005 9:32 AM To: Glenn A. Adams; Johnb@screen.subtitling.com Cc: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming Glenn, The 'problem' with your suggested approach **for me** is that all of the parallel languages would share a common head section (which contains the layout and styling elements). This would make combining languages into a composite multi-language document diificult - imagine if the language to be appended contains style references that match existing ones. Further - extraction also becomes more complex, as it would be necessary/desirable to reduce the head element to only those element instances that are referenced by a specific language. Secondly - since the div element cannot be nested, use of the div element to separate parallel languages, as would be logical for my anticipated use, would effectively remove the ability to use div for any other structural purpose (such as separating program segments). Using annotations for filtering content strikes me as a rather 'weak' approach to solving my requirement.... it also conflicts with other potential uses for the role element - e.g. identification of the 'type' of text it annotates (dialogue, lyrics, description).... and any profile using a 'ttm:role' based styling mechanism. I think it more likely that it will be necessary to generate a profile for DFXP, and probably a DFXP wrapper format to handle the multi-language issue to satisfy my (and others) requirements. regards John Birch -----Original Message----- From: Glenn A. Adams [mailto:gadams@xfsi.com] Sent: 29 March 2005 14:30 To: Johnb@screen.subtitling.com Cc: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming In point 1, I mean DFXP. You could, e.g., place parallel languages in separate div, p, span elts, etc., although this is not a recommended usage for interchange. Then you could use XSLT/XQuery, etc., between your archive and over-the-air inserter (where presumably it would be transformed into some final distribution format, e.g., DVB Subtitles). Also, you could do something similar for annotating content to be filtered in the transform step, e.g., ttm:role="x-adult". _____ From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] Sent: Tuesday, March 29, 2005 8:41 AM To: Glenn A. Adams Cc: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming Hi Glenn, I'm not sure I understand your response? In point 1, do you mean AFXP? cf DFXP. Alternatively, how would you suggest structuring a multi-language DFXP document? w.r.t. point 2, I have perhaps created confusion by referring to a timedtext stream. I did not intend to imply that the content of that element was intended for streaming in the internet sense of the word..... rather I used the term stream as analogous to 'thread'. regards John Birch. -----Original Message----- From: Glenn A. Adams [mailto:gadams@xfsi.com] Sent: 29 March 2005 14:13 To: Johnb@screen.subtitling.com Cc: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming 1. In the main archive, you could have a single DFXP document that combines languages and usages (adult/child), and then use an XSLT transform (or XQuery) to select the portions required for a "send to air" document. 2. While the TTWG does consider streamability to be a necessary property of DFXP, it drew the line at actually defining a streaming form, which was considered out of scope; however, there is nothing to prevent a future specification (either in or out of W3C) from defining such a form. G. _____ From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] Sent: Tuesday, March 29, 2005 7:22 AM To: Glenn A. Adams Cc: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming Glenn, Current practice for subtitling in broadcast TV is to hold an archive of all subtitle files for all material that has been, will be, or may be broadcast. This can amount to many tens of thousands of files. (David can probably give you a number for the BBCs archive!) Current practice (at least for us) is to combine all individual language files into a single multi-language package for a given program. So, subtitle files are originated by subtitlers in a single language - and transferred, QA'd and then typically combined into a multi-language 'air' file. These 'air' files are then held in a 'subtitle archive' that can be accessed by the insertion systems when station automation requests the playout of a particular piece of material. Typically for a European operation there may be on average 4-6 languages present in each multi-language file (although we have systems with many more langauges per channel than this). There are many models being discussed within the ad-hoc committee, doubtless there will be a transition interval where DFXP content is held externally to the media content. Indeed it may be (for operational reasons) that the combined MXF/AAF with subtitles incorporated internally is only used as a 'between broadcaster' format - not as a near to air format. So, a nominally single language DFXP could result in a proliferation of files (probably by a factor of 4 - 8) for broadcasters. Note - we are assuming that insertion equipment will move across to using DFXP **directly** here. By onerous, there are implementation issues to consider. The increase in the number of files creates a subtle problem. The files have to be referred to by the automation equipment, changing from a multi-lingual system to a single language per file concept means that either the automation system has to send multiple demands to the insertion equipment (for each language) - changing the whole concept of the automation interface, or the insertion equipment has to determine which individual DFXP files constitute the fileset for a given material reference. It is unlikely that many broadcasters will wish to make changes to station automation... this is VERY much an area of "If It Aint Broke Don't Fix It" - by which I mean there is a strong resistance to messing with such a critical aspect of a broadcasters operation. So we can fairly safely assume that the insertion system will need to expand a single material reference into a fileset. This in itself doesn't sound to difficult until you consider that the system will need to be created and maintained by human operators!. At present there is one point of potential failure - the appending of a new subtitle language 'stream' into the archive. With the multiple files approach dictated by DFXP's limitation to single language - more opportunies can arise for problems. So - single language DFXP increases the number of files to handle (by perhaps a factor of 4 - 8), and the omission of a conditional content mechanism may multiply that again.... BTW Is there any practical reason why DFXP couldn't be multi-stream, or is it simply a philosophical issue? What (apart from the schema) prevents a DFXP document having effectively more than one instance of the tt element structure? e.g. (introduction of element tts "timedtext stream") <tt xmlns="http://www.w3.org/2004/11/ttaf1"> <tts xml:lang="fr-fr"> <head> <meta/> <styling/> <layout/> </head> <body/> </tts> <tts xml:lang="en-uk"> <head> <meta/> <styling/> <layout/> </head> <body/> </tts> <tts xml:lang="en-uk-caption"> <head> <meta/> <styling/> <layout/> </head> <body/> </tts> </tt> regards John Birch. -----Original Message----- From: Glenn A. Adams [mailto:gadams@xfsi.com] Sent: 29 March 2005 12:28 To: Johnb@screen.subtitling.com Cc: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming Could you describe what you mean by "subtitle archive" and "onerous to require ..."? _____ From: Johnb@screen.subtitling.com [mailto:Johnb@screen.subtitling.com] Sent: Tuesday, March 29, 2005 3:47 AM To: Glenn A. Adams; russ.wood@softel.co.uk; public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming Glenn, An issue that was discussed recently at the AAF/MXF EBU ad-hoc subtitle commitee.... While the generation of multiple DFXP 'files' for individual languages is an acceptable solution, I feel there may yet be a requirement for a 'lightweight' conditional content mechanism. The specific example I have in mind is to support the concept of viewing 'watersheds' - i.e. content unsuitable for minors. In this case the majority of a subtitle file would be suitable for all viewers - but the odd word or phrase may be 'sanitised' for pre watershed (e.g. 8.00pm) airings of the programme. It would be onerous to require a subtitle archive to retain multiple copies of content to cater for just the alteration of one of two words in a 1300 line subtitle file. Is there any possibility of introducing a conditional content facuility to DFXP that would support this kind of minor use? A second use of this mechanism, which might be a stretch too far, is to support subtitle files that can be used as captions (i.e. near verbatim + sound cues) or as subtitles. In this case the conditional content may be the 'sound cues' and possibly the replacement of some of the subtitle lines with less accurate (but more concise!) translations. best regards John B. -----Original Message----- From: Glenn A. Adams [mailto:gadams@xfsi.com] Sent: 26 March 2005 05:47 To: Russ Wood; public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Profile (DFXP) Streaming DFXP supports general use of xml:lang attribute in order to (1) specify a default language for document instance and (2) to annotation language of nested content. It is up to the author to decide how to use this mechanism. For example, an author could potentially specify different <div/> elements using different languages, or different <p/> elements, etc. Nonetheless, the intention is not to explicitly support in DFXP conditional content selection based on preferred language. In contrast, conditional content selection will be supported in AFXP. The intent with DFXP is to have already made all conditional selections prior to transmitting/exchanging in DFXP format. This means that if an AFXP document supports course granular conditional selection between parallel language representations, then one may produce multiple DFXP document instances from a single AFXP document instance, by enumerating over the condional parameter space (of which each permutation may produce a distinct DFXP document instance). Regards, Glenn _____ From: Russ Wood [mailto:russ.wood@softel.co.uk] Sent: Monday, March 21, 2005 5:36 AM To: public-tt@w3.org Subject: RE: Timed Text Authoring Format - Distribution Format Exchange Pr ofile (DFXP) Streaming 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.
Received on Tuesday, 29 March 2005 14:23:32 UTC