RE: new issue? dfxp and language selection

I think your proposal is eminently sensible... 'works for me' as they
say :-)
 
I note with interest that the use of xml:lang in the spec is not
completely consistent with Extensible Markup Language (XML) 1.1, W3C
Recommendation 04 February 2004 which has the statement...
"A special attribute named xml:lang may be inserted in documents to
specify the language used in the contents and attribute values of any
element in an XML document."
Unless I am mistaken, we do not assume that attribute values within an
element marked by the xml:lang attribute in a DFXP document have values
expressed in that identified language.
 
So I don't see the embedded xml:lang issue in the same way... since for
me the CCForFLASH processing is making a decision based on that
attribute value at a specific document level (namely the div...)
For me the semantic of xml:lang in our specification is only ever
informative about the element content - not the document content. It is
an attribute value on which a processor might make a selection, in the
same way that an xml document representing a database of addresses might
be processed by a processor that uses an attribute value to 'select'
only addresses in a specific geographic region... The choice of which
specific attribute instances should be used for a processing decision is
up to the processing - not the document structure designers.
 
Personally I would go slightly further than you propose... and offer up
the CCForFlash mechanism as an example of (internal) processing... I
personally would expand the spec (perhaps with an appendix) to
demonstrate that CCForFLASH effectively internally creates a conforming
subset of the input DFXP even though the result of that internal
processing is not expressedly output. I find your text slightly
prescriptive as to me it implies that a conforming implementation
transforms the complete document before presentation. Clearly some
implementations may make these transformations 'on the fly' - yet to an
external observer achieve the same effect as a pre-presentation
transformation of the complete document.
 
Perhaps...
 
"The semantics of presentation and layout presented in this section is
the default presentation of an unmodified conforming timed text document
instance. Presentation processors may have modes which transform a timed
text document before or during presentation; For example to subset the
input document and/or to change part or all of the default presentation,
based on user preference settings or the processing of a conforming
input timed text document. 

 

Such processing would still be considered consistent with these
semantics if the  transformation operation is clearly documented as
having the effect of altering a conforming input document and shows how
the post transformation document instance might still be expressible as
a conforming Timed Text document. Such a processor must be considered as
a hybrid transformation and presentation processor."

 
respectfully,
 
John Birch

________________________________

From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On
Behalf Of Sean Hayes
Sent: 04 December 2008 11:28
To: Glenn A. Adams; Public TTWG List
Subject: RE: new issue? dfxp and language selection



In principle I have nothing against a processor, or user, modifying the
offered presentation; after all that is the whole essence of closed
captioning, and allows us for example to take into account the CEA608
and 708 user options.

 

But I'm still not sure the spec should explicitly sanction the way that
ccPlayer has chosen to do this, as it penalises implementations which
have chosen not to adopt this convention and calls into question the
semantics of xml:lang="fr" embedded in an xml:lang="en" context. 

 

So I do not believe we should craft a note documenting this usage of
xml:lang specifically; but possibly a more general note in the
introduction of 9.3 along the lines of:

 

"The semantics of presentation and layout presented in this section is
the default presentation of an unmodified conforming timed text document
insytance, Presentation processors may have modes which transform a
timed text document before presentation; For example to subset, or
change part or all of the default presentation based on user preference
settings, or additional processing of attributes in a conforming timed
text document. 

 

Such processing may still be considered consistent with these semantics
if the  transformation operation is clearly documented as altering the
input document, and shows how the post transformation document is
expressible as a conforming Timed Text document. Such a processor must
be considered as a hybrid transformation and presentation processor."

 

 

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

 

Office:  +44 118 909 5867,  

Mobile: +44 7875 091385

 

From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On
Behalf Of Glenn A. Adams
Sent: 04 December 2008 01:28
To: Public TTWG List
Subject: Re: new issue? dfxp and language selection

 


First, I may say this is not at all a new issue, but in fact a very old
one, one on which we spent many cycles in previous email, telecons, and
face to face meetings.

In these prior discussions, we discussed such issues as:

*	whether to use single or multiple DFXP documents to express
parallel language expressions of the same information; 
*	the utility of xml:lang to describe embedded foreign language
content (in some larger context), such as, e.g., a French language quote
inside an English language paragraph or division; 
*	whether to support the SVG/SMIL <switch/> element; 


Each time we discussed these matters, we concluded that:

1.	in general, distinct DFXP documents should be used to express
distinct language editions of the same content (as opposed to
interleaving); 
2.	that xml:lang should be primarily used to designate the overall
language context, and secondarily any embedded, foreign language
expressions; 
3.	that the SVG/SMIL <switch/> element, while certainly appropriate
for AFXP (our earlier, more fully featured primary authoring, not
distribution format), was not appropriate for DFXP in its role as a
primarily distribution format; 


As for what we should do with the DFXP spec now, I think we should not
try to introduce <switch/> at this late stage, at least in this version
of DFXP. Further, we should encourage adoption of our conclusions, and
to this end, at least a note would be appropriate in the section
describing xml:lang.

However, I believe we can craft a note that permits the behavior
implemented by ccPlayer, which I would describe as a combination of an
implied transformation processor (that performs content selection) and a
presentation processor (that presents the selected content). As such,
ccPlayer is a specialized presentation processor, and not entirely
generic. But we should be able to distinguish between these two types of
presentation applications, at least in an informative manner.

The note I have in mind for xml:lang would be something like the
following:

Note:

The intended usage of the xml:lang attribute is to indicate (1) the
overall language context that applies to a single, overall document
instance, referred to below as the document language, and (2) the
language of embedded content that differs from the document language. It
is not intended, in the default, common usage of DFXP content, that
xml:lang be used to interleave parallel representations of the same
content in different languages in a single document instance; however,
since DFXP content may be used to interchange legacy content in which
such usage does occur, it is not prohibited as a possible usage pattern
for DFXP content.

Any type of DFXP content processor, whether transformation or
presentation oriented, that performs implicit content selection or
filtering based on the use of xml:lang as a selection or filtering
criterion should clearly document this specialized behavior.

The only possible problem with this language, is that it effectively
sanctions the explicitly unintended usage pattern. If an implementation
is widely adopted or distributed, then the presence or absence of
documentation of its specialized behavior will likely make little
difference to its users, and will lead to expectations about the
behavior of other implementations. As such, I do have reservations about
such a sanction. One possible way to get around this might be to define
an IRI that name this variant behavior as an explicit extension, and
then require that a document that relies on this feature to include a
requiredExtensions attribute.

For example,

<tt xml:lang="" xmlns="http://www.w3.org/2006/10/ttaf1"
requiredExtensions="http://www.w3.org/2006/10/ttaf1#extension-filter-by-
language">
<head/>
<body>
<div xml:lang="en"/>
<div xml:lang="fr"/>
<div xml:lang="es"/>
</body>
</tt>

Note, that we have a prior agreement to update the spec to include the
requiredFeatures, requiredExtensions, and requiredFonts attributes,
which would support the above usage.

Given the above, ccPlayer would be modified to look for this
requiredExtensions attribute, and only perform filtering if it were
present. And furthermore, its documentation would included the fact that
it supports this extension.

Regards,
Glenn


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