RE: new issue? dfxp and language selection

Assuming that xml:lang is defined solely for its intended meaning... 

Are you proposing that an alternate **new** attribute be used to support
transformations at a language selection level?
The TT WG spoke many moons ago about user defined 'opaque data'...
Should that concept be resurrected?

John


---Original Message-----
From: Sean Hayes [mailto:Sean.Hayes@microsoft.com] 
Sent: 04 December 2008 15:55
To: John Birch; Daniel Weck
Cc: Glenn A. Adams; Public TTWG List
Subject: RE: new issue? dfxp and language selection

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
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385

John Birch | Screen Subtitling Systems Ltd | Strategic Partnerships Manager
Main Line : +44 (0)1473 831700 | Ext : 270 | Office :  
Mobile: +44 (0)7919 558380 | Fax: +44 (0)1473 830078
john.birch@screen.subtitling.com | www.screen.subtitling.com
The Old Rectory, Claydon Curch Lane, Claydon,Ipswich,IP6 0EQ,United Kingdom


See us at Broadcast Video Expo - February 17th - 19th 2009, Earls Court 2, London, Stand number K56


Before Printing, think about the environment


This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ

Received on Thursday, 4 December 2008 16:07:00 UTC