Re: [Slim] Issue 43: How to know the modality of a language indication?

[Gunnar Hellström <[e-mail]>]

Den 2017-10-14 kl. 04:25, skrev Randall Gellens:
> At 1:46 PM -0700 10/13/17, Bernard Aboba wrote:
>
>>  Issue 43 ( 
>> <https://trac.ietf.org/trac/slim/ticket/43>https://trac.ietf.org/trac/slim/ticket/43 
>> ) results from a review comment that said that a simple way is 
>> required to decide if a language tag is a sign language or a written 
>> or spoken language.
>>
>>  Some applications scan the IANA language registry at startup for the 
>> word "Sign" in the tag description:
>>
>> <https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry>https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry 
>>
>>
>>
>>  Currently, there are 319 language subtags that include "Sign 
>> Language" in their description.
>>  Given the current layout of the language subtag registry, it is not 
>> clear to me that there is an easier way to determine which tags 
>> represent sign languages.  Nor is it within the SLIM WG charter to 
>> develop a modification to the language subtag registry to address 
>> this concern.
>>  So I am wondering whether we might resolve this with a Note 
>> outlining the problem but not offering a solution. 
>
> I think the wording in -14 addresses the comment by accepting Dale's 
> suggestion that, rather than know non-signed tags, it's the use of the 
> exact same tag in both an audio and a video stream that is the 
> indicator.  That both tightens up the technical issue and simplifies 
> it greatly.
>
> The only other instance where we might add such a note would be in 5.4:
>
> 5.4.  Undefined Combinations
>
>    With the exception of the case mentioned in Section 5.2 (an audio
>    stream in parallel with a video stream with the exact same (spoken)
>    language tag), the behavior when specifying a non-signed language tag
>    for a video media stream, or a signed language tag for an audio or
>    text media stream, is not defined.
>
> We could add your suggested note to 5.4.
>
<GH>We can replace 5.4 with a more explicit section guiding applications 
to how to make the deduction simple. So, instead of a note, I suggest 
that we replace 5.4 with:

5.4 Relations between media and modality
There is no easy way to deduct the intended modality from a language 
tag. Other specifications may introduce specific notations for modality 
used in a media or in relation to a language tag. Applications not 
implementing such specific notations may use the following simple 
deductions.
- A language tag in audio media is supposed to indicate spoken modality.
- A language tag in text media is supposed to indicate  written modality.
- A language tag in video media is supposed to indicate visual sign 
language modality except for the case when it is supposed to indicate a 
view of a speaking person mentioned in section 5.2 characterized by the 
exact same language tag also appearing in an audio media specification.
- A language tag in media where the modality is obvious or specified for 
the media subtype definition is supposed to indicate that modality.
- A language tag in other media descriptions than above has undefined 
modality.
---------------------------------------------------------------------------------------------------------------------

My note:  by this we currently consciously exclude the following use and 
I am ok with that:
-text in mp4 video
-audio in mp4 video ( or is that only allowed in application/mp4 ??)
-any modality in message media
-most application media, however some may have explicit descriptions in 
subtype specifications.

The exception with a view of a speaker stands out as very odd now, 
requiring comparison of language tags used in different media 
descriptions, and requiring simultaneous use of language in two 
different media that is otherwise out of scope for this draft. It was 
introduced while I still hoped that we could introduce other 
dependencies between language use in different media.  It is not the 
most urgent media/language combination to specify. It is also handled in 
draft-hellstrom-slim-modality-grouping. So, assuming that we can get 
progress on that draft, we could clean up the current draft by deleting 
the exception. I suggest that we delete the exception.

/Gunnar



-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]