This is a collection of the answers to be sent to I18N people after their comments summarized in http://www.w3.org/International/reviews/0603-pls10/. The current draft of the whole Disposition of Comments can be found here.
| Item | Commentator | Nature | Disposition |
|---|---|---|---|
| R103-1 | Richard Ishida (2006-03-21) | Feature Request | Reject |
| R103-2 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-3 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Reject |
| R103-4 | Richard Ishida (2006-03-21) | Technical Error | Accept |
| R103-5 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-6 | Richard Ishida (2006-03-21) | Technical Error | Accept |
| R103-7 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Under Discussion |
| R103-8 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-9 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Reject |
| R103-10 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-11 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-12 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-13 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-14 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Reject |
| R103-15 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Reject |
| R103-16 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Under Discussion |
| R103-17 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-18 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-19 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Defer |
| R103-20 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-21 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Reject |
| R103-22 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-23 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-24 | Richard Ishida (2006-03-21) | Change to Existing Feature | Reject |
| R103-25 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-26 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Reject |
| R103-27 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-28 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-29 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-30 | Richard Ishida (2006-03-21) | Feature Request | Reject |
| R103-31 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Reject |
| R103-32 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Reject |
| R103-33 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Reject |
| R103-34 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Accept |
| R103-35 | Richard Ishida (2006-03-21) | Clarification / Typo / Editorial | Under discussion |
| R103-36 | Richard Ishida (2006-03-21) | Feature Request | Accept |
From Richard Ishida (2006-03-21):
Proposed Classification: Feature Request
Resolution: Reject
This request is outside the current scope of PLS specification which describes the format of a PLS document. It does not describe how the PLS document will be activated in another markup.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We accept your request. All the examples in the PLS specification will be changed by moving the "numerical character references" into the XML comments and the IPA unicode characters into the PLS elements.[[ C047 [I] [C] Escapes SHOULD only be used when the characters to be expressed are not directly representable in the format or the character encoding of the document, or when the visual representation of the character is unclear. ]]
From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Reject
We believe this request is outside the current scope of the PLS specification. That stated, we believe that adding support for an embedded lexicon within SSML and SRGS documents is valuable and should be considered for future versions of those specifications.
From Richard Ishida (2006-03-21):
Proposed Classification: Technical Error
Resolution: Accept
We agree that the Schema needs to be fixed. Our idea was to have a strict order of meta, metadata and then lexeme elements.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
You are welcome!From Richard Ishida (2006-03-21):
Proposed Classification: Technical Error
Resolution: Accept
We accept your comment. All the examples will be revised using consistent IPA characters in the transcriptions.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Under Discussion
We would like to ask for clarifications to better understand your request. If you see specific points to be clarified, please identify specific paragraphs that need clarifications.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We accept your correction and will fix the specification accordingly.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Reject
In this example, a TTS synthesizer is rendering the text using the voice of an American English speaker (xml:lang="en-US"). The SSML specification contains the following warning about changing the language indication in midsentence [1]:xml:lang is a defined attribute for the voice, speak, p, and s elements. For vocal rendering, a language change can have an effect on various other parameters (including gender, speed, age, pitch, etc.) which may be disruptive to the listener. There might even be unnatural breaks between language shifts. For this reason authors are encouraged to use the voice element to change the language. xml:lang is permitted on p and s only because it is common to change the language at those levels.and continues:
Specifying xml:lang does not imply a change in voice, though this may indeed occur. When a given voice is unable to speak content in the indicated language, a new voice may be selected by the processor.To avoid a potential incongruity, the language change was not indicated in this example.
From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We accept your correction and will fix the specification accordingly.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We will add an example lexicon to Section 1.1 [1].From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We accept your correction and will fix the specification accordingly.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
Our proposal is to delete the sentence you mentioned.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Reject
To our knowledge, there is no online version of the IPA handbook so we must normatively reference the printed book. The link you mention is a page on the web that describes how to acquire the printed copy.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Reject
We asked Ian Jacobs, the Comm Team head, about the reference to software from a recommendation track specification.Link to software from the group's public home page, not from the spec. Links to software from specs are likely to become outdated rapidly.On the basis of this comment, we decided to reject your request and instead add a link to the IPA Character Picker tool in the Voice Browser Home-Page.
From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Under discussion
We think your request is reasonable, but we would like to know if there are Guidelines on this subject for the Spec authoring.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We accept the wording you suggested.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We accept the wording you suggested.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Defer
We imagine that a future version of PLS will be multilingual. However, for the first version, we'd prefer to defer this request.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We accept you request and we'll make the following changes:We will replace 'RFC 3066 [RFC3066]' with 'IETF Best Current Practice 47 [BCP47]'
We will add a normative reference to [BCP47] as in [3]
From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Reject
We do not see any relationship between the two declarations. The attribute xml:lang is mandatory in PLS and dc:language will be ignored.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
The example you mention is not "4.3, 2nd example", but it should be "4.4 example".From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We will use "it" instead of "it-IT". This example is not specific to Italian language spoken in Italy.From Richard Ishida (2006-03-21):
Proposed Classification: Change to Existing Feature
Resolution: Reject
The observation that the element named 'grapheme' [1] almost always involves a *sequence* of graphemes is quite true. However, it is not a requirement for the element to contain a *sequence* of graphemes; only one grapheme (smallest orthographic unit) is permissible (minimum requirement). This is why the element is named 'grapheme' rather than 'graphemes'. The grapheme or sequence of graphemes given in the 'grapheme' element corresponds to the phoneme or sequence of phonemes given in the 'phoneme' element. This is in accordance with the notion of "grapheme-to-phoneme conversion" (or, in layman's terms, letter-to-sound conversion). The name of the element 'grapheme' goes hand-in-hand with the name of the element 'phoneme', which has been borrowed from SSML 1.0 [1] because it has a similar usage.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We accept you comment by changing the third bullent in Section 4.5 [1]. The proposed text is the following which includes an inline example of mixed scripts:Alternate writing systems, e.g. Japanese uses a mixture of Han ideographs (Kanji), and phonemic spelling systems (Katakana or Hiragana) for representing the orthography of a word or phrase, and such mixture sometimes has several variations as in kana suffixes following kanji stems (Okurigana) for example "okonau" (行なう vs. 行う);.Please indicate whether you are satisfied with the VBWG's resolution, whether you think there has been a misunderstanding, or whether you wish to register an objection.
From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Reject
The following text appears in Section 4.5 [1]:"In order to remove the need for duplication of pronunciation information to cope with the above variations, the <lexeme> element may contain more than one <grapheme> element to define the base orthography and any variants which should share the pronunciations."We believe that there is general utility, beyond text-to-speech, for supporting multiple graphemes. To illustrate one such case, the following lexicon might be used for US English:
<?xml version="1.0" encoding="UTF-8"?>
<lexicon version="1.0" xmlns="http://www.w3.org/2005/01/pronunciation-lexicon"
alphabet="ipa" xml:lang="en-US">
<lexeme>
<grapheme>judgment<\grapheme>
<grapheme>judgement<\grapheme>
<phoneme>ˈʤʌʤ.mənt<\phoneme>
<\lexeme>
<lexeme>
<grapheme>fiancé<\grapheme>
<grapheme>fiance<\grapheme>
<phoneme>fiˈɑ̃ːn.seɪ<\phoneme>
<phoneme>ˌfiː.ɑːnˈseɪ<\phoneme>
<\lexeme>
</lexicon>
In text-to-speech documents, as has been noted,
<?xml version="1.0" encoding="UTF-8"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xml:lang="en-US">
<lexicon uri="http://www.example.com/lexicon_defined_above.xml"/>
<p> In the judgement of my fiancé, Las Vegas is the best place for a honeymoon.
I replied that I preferred Venice and didn't think the Venetian casino was an
acceptable compromise.<\p>
</speak>
but also in speech recognition grammars,
<?xml version="1.0" encoding="UTF-8"?>
<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
xml:lang="en-US" root="movies">
<lexicon uri="http://www.example.com/lexicon_defined_above.xml"/>
<rule id="movies" scope="public">
<one-of>
<item>Terminator 2: Judgment Day<\item>
<item>My Big Fat Obnoxious Fiance<\item>
<item>Pluto's Judgement Day<\item>
<\one-of>
<\rule>
</grammar>
We feel that this is used both for TTS and ASR therefore we reject
your proposal to add only "text-to-speech".
From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We decided to remove the "orthography" attribute. We also do not see its value and recognize the benefits of supporting a mixture of script types within a grapheme element.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
As we will remove the "orthography" attribute, this comment reduces to the accurate transcription of the 2nd example in Section 4.5 [1].From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We will change the word 'transformations' to 'substitutions'.From Richard Ishida (2006-03-21):
Proposed Classification: Feature Request
Resolution: Reject
The <example> element has XML Schema type 'string' [1] which allows embedding of directionality marks and overrides (e.g. 0x200E, 0x200F, 0x202D, 0x202E, 0x202C). We've reviewed the I18N FAQ [2] and Unicode Technical Report #20 [3] and believe that embedded character codes are appropriate for the <example> element.
PLS documents cover a single language. We've assumed that the examples would be in the same language as the lexicon and that adding xml:lang to <example> was therefore unnecessary. In the case of 'borrowed' words such as 'hors d'oeuvres', the example would be written in the borrowing language as in "<example>As an appetizer, he prepared a wide selection of hors d'oeuvres such as cucumber sandwiches and garlic hummus with baked pita.</example>".
From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Reject
The examples in section 5.3 [1] do not strictly contain homophones. A pair of homophones is two different *words* (thus, with two different *meanings*) that have the same pronunciation. Each example in 5.3 contains one word that can be written in different ways and that retains the same meaning and pronunciation.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Reject
We can clarify the Section 5.4 [1] by splitting the example in two parts. First the seed/cede examples and then the Smyth/Smith. We believe that PLS is most valuable for addressing the difficult cases that arise in human speech. We see a value to maintaining complex examples to illustrate how an author might address these complex cases.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Reject
The two main uses of PLS are for SRGS (ASR) and SSML (TTS). In both these cases the PLS are applied on grapheme to define the phonemes to be recognized (for ASR) and to be pronounced (for TTS). There are other uses of PLS, for instance in a dictation or for unconstrained ASR, but which might not be covered by the current specification.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Accept
We will check all the pronunciation transcriptions with phoneticians. On the example in Section 5.5 [1] we found this IPA transcription in both the Cambridge online dictionary [2] and in the book version of Longman Pronunciation Dictionary by JC Wells. Both these resources shows IPA pronunciations. Merriam-Webster (more US-centric) [3] uses a different pronunciation alphabet but gives a very similar pronunciation to the ones in the examples.From Richard Ishida (2006-03-21):
Proposed Classification: Clarification / Typo / Editorial
Resolution: Under discussion
The resolution of issue #36 will significantly change Section 5.5 [1]. We will propose new wording and we will welcome your review.From Richard Ishida (2006-03-21):
Proposed Classification: Feature Request
Resolution: Accept
We accept your proposal to add an attribute in the PLS as a way of uniquely matching homographs to pronunciations.