Re: [css3-speech] voice family prohibition of spaces

On 7 Jun 2011, at 02:25, fantasai wrote:

> On 06/07/2011 03:47 AM, Daniel Weck wrote:
>> Good point. Voice names are space-separated in SSML's 'name'  
>> attribute, but values are comma-separated in the 'voice-family'
>> CSS property. I agree that the CSS Speech module should allow  
>> spaces in (quoted) voice names,
>
> I agree. Certainly the CSS Speech module should not make any  
> restrictions on
> string values. It can make restrictions on unquoted names, however.
>
> Possibilities:
>  - Allow unquoted names per font-family, concatenating adjacent  
> idents with a single space.
>  - Allow unquoted names per font-family, concatenating adjacent  
> idents with a single underscore.
>  - Allow unquoted names only as a single ident. This would work fine  
> for names with underscores,
>    but names with spaces would need quoting.

Yes, we need to disambiguate the handling of adjacent, whitespace- 
separated identifiers. I prefer option #1, as this matches 'font- 
family':

http://www.w3.org/TR/CSS21/fonts.html#font-family-prop

"
If a sequence of identifiers is given as a font family name, the  
computed value is the name converted to a string by joining all the  
identifiers in the sequence by single spaces.
"

>> but the question is whether or
>> not the specification should define the algorithm to convert from/ 
>> to SSML voice names. It is unclear from the SSML1.1
>> Recommendation whether spaces can be escaped with their unicode  
>> equivalent (U+0020, or   in hexadecimal, or   in
>> decimal notation). Thoughts welcome. Regards, Daniel
>>
>> http://dev.w3.org/csswg/css3-speech/#voice-props-voice-family
>>
>> http://www.w3.org/TR/speech-synthesis11/#edef_voice
>
> You cannot escape spaces like that in XML. Except for characters  
> that are
> part of XML syntax, where escaping changes whether they are treated  
> as XML
> syntax or as literal characters, escaping does not change the  
> meaning of
> the XML file and the escaped characters are parsed in as a regular  
> character
> stream.

Yes, I shouldn't have given the ampersand-encoded entity values as an  
example, as it is misleading. What I meant was that some kind of  
escaping notation based on the unicode entry point could be used  
"locally" in the SSML voice name attribute syntax. The editors of SSML  
didn't chose to enable spaces via a well-defined escaping mechanism,  
probably for simplicity...I'm not sure. I actually found a comment  
dated back to 2003, but I can't find a follow-up:

http://lists.w3.org/Archives/Public/www-voice/2003JulSep/0030.html

"
name attribute: No whitespace in the name seems overly restrictive -  
why not just comma separate the list of names as with font-face is  
CSS? The voice names are implementation dependent, therefore if  
whitespace is not allowed the SSML implementor will potentially have  
to map native voice names to SSML voice names, which seems to make  
SSML harder to use for developers (and possibly users).
"
Cheers, Daniel

Received on Tuesday, 7 June 2011 07:24:59 UTC