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