Re: Advice on MediastreamTrack.label

Adding Peter to the CC list.

Den 09. juni 2015 18:52, skrev Harald Alvestrand:
> On 06/09/2015 05:54 PM, Phillips, Addison wrote:
>> Hi Harald,
>>
>> Thanks for the note. I've copied our WG list since this is a WG comment and since others may have informative opinions.
>>
>>> Do you think
>>> it's appropriate to say that Label is returned in the language of
>>> window.navigator.language when possible
>> I think it would be better to say something like:
>>
>> --
>> The user-agent SHOULD provide a language tag for each label where available. Often language information about the label is not available; in these cases the user-agent should omit the language tag. Callers might infer the language from window.navigator.language or from other metadata about the resource.
>> --
> 
> The problematic thing is that this requires extending our data
> structures with language tags - there isn't a place in the structure now
> for metadata that applies to the whole list of device labels, and the
> other extreme of per-label marking (for example wrapping each DOMstring
> into a MediaCapture-specific structure containing the string and a
> language tag) seems like overkill.
> 
>>
>> That avoids creating inaccurate metadata when information isn't available (in fact, it is what current implementations probably do), while allowing language information to be provided when it is available.
>>
>>> and is there a way to determine
>>> an appropriate @dir from the navigator context, or should we just say "the
>>> string assumes that it will be embedded in an LTR context"?
>> It doesn't matter which direction context the string might be embedded into. Recent changes in the Unicode Bidirectional Algorithm and reflected in HTML5 suggest that any such inclusions be "isolated", although that is not a problem that Mediastream needs to deal with (you're just providing the value). The problem is that the caller still needs a base direction for the string--particularly for cases where the string is not consistent with the surrounding context or where the string contains strongly directional characters that would "fool" the Unicode Bidi Algorithm.
> 
> Or where the string starts with numbers :-(
>>
>> I think the recommendations here would be along similar lines: provide the information where available and omit it when it is not. It may make sense for the caller to estimate the direction using the same algorithm as HTML5 uses (see [1] discussing @dir = auto). 
> Again - at what level shold this info be provided?
> 
> DOMStrings don't have dir tags. And unlike "lang", "dir" information
> isn't available at Navigator either.
> 
>>
>> Hope that helps,
>>
>> Addison
>>
>> [1] http://www.w3.org/TR/html5/dom.html#the-dir-attribute
>>
>>
>>> -----Original Message-----
>>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>>> Sent: Tuesday, June 09, 2015 12:42 AM
>>> To: Phillips, Addison; Stefan Håkansson LK
>>> Subject: Advice on MediastreamTrack.label
>>>
>>> Hi Addison,
>>>
>>> I'm trying to see what we can do about your comment about "label" that is
>>> both implementable and sensible.
>>>
>>> Current draft text in response:
>>>
>>> https://www.w3.org/2006/02/lc-comments-tracker/47318/WD-
>>> mediacapture-streams-20150414/3026
>>>
>>> with suggested text:
>>>
>>> This issue is thorny. Since the mediaDevices.enumerateDevices call is only
>>> defined on Navigator, we ask whether it's possible to state that the @lang
>>> attribute is window.navigator.language, and whether it's appropriate to
>>> determine @dir via the same method.
>>>
>>>
>>> This is asking a question rather than giving an answer - tell me: Do you think
>>> it's appropriate to say that Label is returned in the language of
>>> window.navigator.language when possible, and is there a way to determine
>>> an appropriate @dir from the navigator context, or should we just say "the
>>> string assumes that it will be embedded in an LTR context"?
> 
>

Received on Thursday, 11 June 2015 14:09:12 UTC