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-lang
uage˛>
<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

Received on Thursday, 4 December 2008 01:28:21 UTC