W3C home > Mailing lists > Public > public-tt@w3.org > December 2008

RE: new issue? dfxp and language selection

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Thu, 4 Dec 2008 15:54:40 +0000
To: John Birch <john.birch@screen.subtitling.com>, Daniel Weck <daniel.weck@gmail.com>
CC: "Glenn A. Adams" <gadams@xfsi.com>, Public TTWG List <public-tt@w3.org>
Message-ID: <90EEC9D914694641A8358AA190DACB3D2FCE9A1A62@EA-EXMSG-C334.europe.corp.microsoft.com>

I tend to side with the view that we should try not to prejudge the ways in which processing of Timed Text will happen, we have called out presentation as an important processing mode as that is important for interoperability, but there are clearly going to be others, which is why we allow the concept of a transformation processor.

I'm not sure that a built in <switch> or switch like attributes is the best option for Timed Text either; much the same and a great deal more can be achieved by XSL type transformations (although clearly the actual processing doesn't have to use XSL technologies, merely something equivalent); for both tree restructuring and presentational styling. These to me seem preferable, for the fact that a) they are predefined and external to timed text, and thus we don't have to invent anything, and b) they are more general.

Whether an author chooses to combine multiple languages in the same document, or multiple roles, or multiple styles of presentation or whatever, and rely on a transformation processor to fish out the bits they are interested in for some specific scenario is a specialised protocol above and beyond the timed text format itself, which the specification should anticipate as a combination of transformation and presentation but not define; which is what I tried to capture with my previous language.

In my opinion the best approach here is having the spec define xml:lang solely for its intended meaning, that is to convey the language of an element and its contents and not try and overlay some other semantics in the specification, but allow interested parties to do so via transformation if they so wish.

I do agree with Glenn that it will be prudent to mark the content in some way if it relies on some such protocol in order to be intelligible, to avoid GIGO type confusions; and that we should specify the mechanism for that marking in order for content to be interoperable.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit

Office:  +44 118 909 5867,
Mobile: +44 7875 091385
Received on Thursday, 4 December 2008 15:56:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:03 UTC