Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)

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

Addison,

Den 2017-02-14 kl. 21:39, skrev Phillips, Addison:
> I have some allergy to the SHALL language: there is no way to automatically determine conformance. Many language tags represent nonsensical values, due to the nature of language tag composition. Content providers need to use care in selecting the tags that they use and this section is merely pointing out good guidance for tag selection, albeit in a heavy-handed way. BCP47 RFC 5646 Section 4.1 [1] already provides most of this guidance and a reference to that source might be useful here, if only because that document requires it:
>
> <quote>
>     Standards, protocols, and applications that reference this document
>     normatively but apply different rules to the ones given in this
>     section MUST specify how language tag selection varies from the
>     guidelines given here.
> </quote>
>
> I would suggest reducing the SHALL items to SHOULD.
Accepted.
That also opens up for another use we have discussed before but been 
advised to not use. That is to indicate use of written language by 
attaching a script subtag even if the script subtag we use is suppressed 
by BCP 47. We can dro that need however, with the use of the Zxxx script 
subtag for non-written, and clearly include that usage in our 
specification as required from BCP 47.
>
> I'm not sure what #2 really means. Shouldn't text captions be indicated by the written language rather than the spoken language? And I'm not sure what "spoken/written language" means.
#2 was: "

2.    Text captions included in the video stream SHALL be indicated
by a Language-Tag for spoken/written language."

Yes, the intention is to use written language in the video stream. There 
are technologies for that.
Since the language subtags in the IANA registry are combined for spoken 
languages and written languages, I call them Language-Tags for 
spoken/written language.
It would be misleading to say that we use a Language-Tag for a written 
language, because the same tag could in another context mean a spoken 
language.
Since we have the script subtag Zxxx for non-written, we do not need to 
construct an explicit tag for the written language tag, it should be 
sufficient with our specification of the use in our case.

In my latest recent proposal, I still have a very similar wording. Since 
you had problems understanding it, there might still be a need to tune 
it. Can you propose wording?
This is the current proposal:

"   2.    Text captions included in the video stream SHOULD be indicated
   by a humintlang attribute with Language-Tag for spoken/written language.
"

Regards
Gunnar
>
> Regards,
>
> Addison
>
> Addison Phillips
> Principal SDE, I18N Architect (Amazon)
> Chair (W3C I18N WG)
>
> Internationalization is not a feature.
> It is an architecture.
>
> [1] https://tools.ietf.org/html/bcp47#section-4.1
>
> -----Original Message-----
> From: SLIM [mailto:[e-mail]] On Behalf Of Gunnar Hellström
> Sent: Tuesday, February 14, 2017 11:59 AM
> To: Randy Presuhn <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
>
> Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
>
>> Hi -
>>
>> On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>> At 11:01 AM +0100 2/14/17, Gunnar Hellström wrote:
>>>
>>>>   My proposal for a reworded section 5.4 is:
>>>>
>>>>   5.4.  Unusual language indications
>>>>
>>>>   It is possible to specify an unusual indication where the language
>>>> specified may look unexpected for the media type.
>>>>
>>>>   For such cases the following guidance SHALL be applied for the
>>>> humintlang attributes used in these situations.
>>>>
>>>>   1.    A view of a speaking person in the video stream SHALL, when it
>>>> has relevance for speech perception, be indicated by a Language-Tag
>>>> for spoken/written language with the "Zxxx" script subtag to
>>>> indicate that the contents is not written.
>>>>
>>>>   2.    Text captions included in the video stream SHALL be indicated
>>>> by a Language-Tag for spoken/written language.
>>>>
>>>>   3.    Any approximate representation of sign language or
>>>> fingerspelling in the text media stream SHALL be indicated by a
>>>> Language-Tag for a sign language in text media.
>>>>
>>>>   4.    When sign language related audio from a person using sign
>>>> language is of importance for language communication, this SHALL be
>>>> indicated by a Language-Tag for a sign language in audio media.
>>> [RG] As I said, I think we should avoid specifying this until we have
>>> deployment experience.
>> ...
>>
>>  From a process perspective, it's far easier to remove constraints as a
>> specification advances than it is to add them.
> I agree. It is often better to specify normatively as far as you can imagine, so that interoperability and good functionality is achieved.
> Stopping halfway and have MAY in the specifications creates uncertainty and less useful specifications.
>
> Furthermore, in this case we succeeded to discuss and sort out the interpretation of the unusual combinations.
> I am very glad that we sorted out the difference between 1 and 2, and they are both real-life cases.
>
> 3 is not at all common, but I have seen products claiming to work for real-time communication with sign representation in text. So it is good to have it settled.
>
> 4. Is a bit more far fetched and may cause some questioning if there are real cases, and where the line should be drawn between indicating a spoken languge in the audio stream and indicating a sign language in the audio stream.
> As I wiew it now, this combination will be very rare, but it is anyway good to be specific and normative about its coding.
>
> Gunnar
>
>> Randy
>>
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitor
> [e-mail]
> [phone]
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

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