Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document details the responses made by the Voice Browser Working Group to issues raised during the second Last Call (beginning 20 August 2001 and ending 28 September 2001) review of Speech Recognition Grammar Specification. Comments were provided by Voice Browser Working Group members, other W3C Working Groups, and the public via the www-voice-request@w3.org (archive) mailing list. The subsequent specification revision is the Candidate Recommendation (June 26th, 2002).
This document of the W3C's Voice Browser Working Group describes the disposition of comment as of 2002/06/20 on the Speech Recognition Grammar Specification second Last Call. It may be updated, replaced or rendered obsolete by other W3C documents at any time.
For background on this work, please see the Voice Browser Activity Statement.
This document describes the disposition of comments in relation to the Speech Recognition Grammar Specification 2nd Last Call (http://www.w3.org/TR/2001/WD-speech-grammar-20010820/). Each issue is described by the name and contact information of the commentator, a description of the issue, and either the resolution or the reason that the issue was not resolved.
The subsequent revision of the Speech Recognition Grammar Specification is the Candidate Recommendation (June XXth, 2002).
The full set of Issues raised for the Speech Recognition Grammar Specification since January 2001, the resolution and in most cases the reasoning behind the resolution are available from http://www.w3.org/Voice/Group/2002/grammar/grammar-cr-20020512.html [W3C Members Only]. This document provides the analysis of the 84 issues that were submitted and resolved internally to the Working Group.
Notation: Each original comment is tracked by a "Grammar Change" [GC] designator. Each point within that original comment is identified by a point number. For example, "GC05-1" is the first point in the fifth comment on the specification.
| Item | Commentator | Nature | Disposition |
| GC01-1 | Al Gilman | Feature Request (§2.4) | Accepted |
| GC02-1 | Al Gilman | Feature Request (§2.4) | Accepted |
| GC03-1 | Al Gilman | Change to Existing Feature (§2.3) | Accepted |
| GC04-1 | Urquhart | Change to Existing Feature (§2.3) | Acknowledged |
| GC05-1 | Laura Werner | Change to Existing Feature (§2.3) | Accepted |
| GC05-2 | Laura Werner | Change to Existing Feature (§2.3) | Accepted |
| GC05-3 | Laura Werner | Technical Error (§2.2) | Accepted |
| GC05-4 | Laura Werner | Technical Error (§2.2) | Accepted |
| GC05-5 | Laura Werner | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC06-1 | Susan Lesch | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC07-1 | Al Gilman | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC08-1 | Martin Duerst | Change to Existing Feature (§2.3) | Rejected |
| GC08-2 | Martin Duerst | Change to Existing Feature (§2.3) | Acknowledged |
| GC08-3 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC08-4 | Martin Duerst | Feature Request (§2.4) | Rejected |
| GC08-5 | Martin Duerst | Feature Request (§2.4) | Accepted |
| GC08-6 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC08-7 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC08-8 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC08-9 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC08-10 | Martin Duerst | Change to Existing Feature (§2.3) | Accepted |
| GC08-11 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC08-12 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC08-13 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC08-14 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC08-15 | Martin Duerst | Change to Existing Feature (§2.3) | Accepted |
| GC08-16 | Martin Duerst | Feature Request (§2.4) | Accepted |
| GC08-17 | Martin Duerst | Change to Existing Feature (§2.3) | Rejected |
| GC08-18 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC08-19 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC09-1 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC09-2 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC09-3 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Rejected |
| GC09-4 | Martin Duerst | Technical Error (§2.2) | Accepted |
| GC09-5 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC09-6 | Martin Duerst | Change to Existing Feature (§2.3) | Accepted |
| GC09-7 | Martin Duerst | Change to Existing Feature (§2.3) | Dissent |
| GC09-8 | Martin Duerst | Change to Existing Feature (§2.3) | Accepted |
| GC09-9 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC09-9a | Martin Duerst | Change to Existing Feature (§2.3) | Rejected |
| GC09-10 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC09-11 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC09-12 | Martin Duerst | Change to Existing Feature (§2.3) | Rejected |
| GC09-13 | Martin Duerst | Change to Existing Feature (§2.3) | Accepted |
| GC09-14 | Martin Duerst | Change to Existing Feature (§2.3) | Accepted |
| GC09-15 | Martin Duerst | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC09-16 | Martin Duerst | Change to Existing Feature (§2.3) | Rejected |
| GC09-17 | Martin Duerst | Change to Existing Feature (§2.3) | Accepted-Rejected |
| GC09-18 | Martin Duerst | Change to Existing Feature (§2.3) | Rejected |
| GC09-19 | Martin Duerst | Change to Existing Feature (§2.3) | Accepted |
| GC09-20 | Martin Duerst | Change to Existing Feature (§2.3) | Dissent |
| GC09-21 | Martin Duerst | Change to Existing Feature (§2.3) | Accepted |
| GC10-1 | Susan Lesch | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC10-2 | Susan Lesch | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC10-3 | Susan Lesch | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC10-4 | Susan Lesch | Clarification / Typographical / Editorial (§2.1) | Accepted |
| GC10-5 | Susan Lesch | Change to Existing Feature (§2.3) | Accepted |
| GC10-6 | Susan Lesch | Clarification / Typographical / Editorial (§2.1) | Accepted |
From Laura Werner
Appendix D again... The MimeTypeChar production is not defined.
Resolution: Accepted
The MimeTypeChar production and five other externally defined patterns are now defined by reference to the relevant IETF RFC or W3C Recommendation.
From Susan Lesch
Here are just a few additional comments for your speech grammar Last Call Working Draft [1]. The comments [2] that I sent you for the last Last Call Working Draft have not been addressed yet and still stand. Sorry for any overlap. If I can be of assistance getting them all incorporated into your next publication, please let me know. [1] Globally, white-space and whitespace -> white space (if you want to follow XML 1.0, see http://www.w3.org/TR/REC-xml#sec-white-space). [2] Globally, working draft -> Working Draft and working group -> Working Group to match the W3C Process document (see http://www.w3.org/Consortium/Process/) [3] Globally, Media type -> media type Below, a section number is followed by a quote and then a suggestion. [4] Abstract representating representing [5] 2.1 aka a.k.a. [6] 2.2.2 http header HTTP header specifes specifies [7] 2.3 The comment in the final XML example should be marked up <!-- --> not // [8] 2.4.1 Please move references to an informative references section. [9] 2.5 Although it both ABNF and XML support Although both ABNF and XML support [10] In 2.7, this sentence is irregular: In situations where applications target a multilingual user community it may be needed for grammars contain words in different languages. could read: In situations where applications target a multilingual user community, grammars that contain words in different languages may be needed. [11] 2.7 Multiple language Multiple languages [12] 3.1 and 4.1 semi-colon semicolon [13] 3.2 referencable referenceable (or reword) [14] 4.1.3 a alias reference an alias reference [15] 4.1.5 tag-format declaration tag format declaration [16] 4.2 http header HTTP header [17] 4.2 (twice) and 4.3 preceed precede [18] F. XML Form grammar to the Augmented BNF Form XML form grammar to the augmented BNF form (or change "forms" in Appendix G) [19] H. Please move the reference to a references section. [20] concatention (twice) concatenation [21] Speech Recognition Grammar Format Speech Recognition Grammar format [1] http://www.w3.org/TR/2001/WD-speech-grammar-20010820/ [2] http://lists.w3.org/Archives/Public/www-voice/2001JanMar/0005.html Best wishes for your project,
Resolution: Accepted
Working Group accepted and applied all the editorial comments from Susan Lesch. See also GC07-1 on white space terminology.
From Al Gilman
At 11:33 PM 2001-09-23 , Susan Lesch wrote: > >Globally, white-space and whitespace -> white space (if you want to >follow XML 1.0, see http://www.w3.org/TR/REC-xml#sec-white-space). > Good edit, bad reference. The section cited above deals only with 'white space' appearing outside the markup. For the definition of what is to be considered as white space it depends on the syntax presented earlier in Common Syntactic Constructs http://www.w3.org/TR/REC-xml#sec-common-syn which is a better location to point to for the definition as used in XML 1.0. BTW if it is to be spelled 'white space' I would prefer it be glossarized with a reference to the XML specification. If agglutenated as one word it is easy to recognize that the technical sense including carriage return and line feed is intended. If spelled with two words it is more possible that readers will miss this nicety. Al
Resolution: Accepted
Working Group glossarized 'white space' and provided a normative definition of white space handling in both the ABNF Form and XML Form of SRGS. The normative definition follows the normative definition in XML 1.0 with the suggested reference.
From Martin Duerst
18) Please use more non-English examples.
Resolution: Accepted
The specification now contains additional examples in Korean, Swedish and Japanese in addition to prior use of French. See, in particular, Appendix J.
From Martin Duerst
Misha Wolf adds: To Martin's: > 15) 4.1.1, 3rd para: 'the character encoding is optional': > It is only optional in some cases (please clarify), > and strongly recommended. I would add (this was discussed at our recent ftf) that the phrase "the character encoding is optional" doesn't make sense. You probably mean something like "the character encoding declaration is optional". The same applies to the phrase "XML document without a character encoding." Both phrases occur in [1]:
Resolution: Accepted
Clarification is correct and the text now reads "character encoding declaration".
From Martin Duerst
1) 1.1: The term DTMF appears many times before it is introduced.
Please give its expansion/explanation the first time it appears.
Resolution: Accepted
DTMF (Dual Tone Multi Frequency) is defined in a new terminology section with appropriate hyperlinks and expansion upon first use of the acronym.
From Martin Duerst
2) Conversion between formats: In case two formats are kept,
to have fully implemented conversion tools in both directions
implemented and tested should be a CR exit requirement.
Resolution: Accepted
The Implementation Report Plan for SRGS requires bi-direction conversion of grammars as an exit condition for the Candidate Recommendation stage.
From Martin Duerst
3) '1.4 Semantic Interpretation': The term 'semantics' is heavily
used (and misused) in various contexts. The use here bears
a serious risk of confusion with the Semantic Web. It is
difficult to understand what exactly this 'semantic interpretation'
is supposed to be, but at the moment, it looks mostly like
events fired upon detection of some input, with associated
scripts. In that case, it would be much better to use the
events/script terminology and maybe also the syntax.
Resolution: Rejected
The term "Semantic Interpretation" is a term of art in the speech technology field and the VBWG felt it appropriate to continue use of the term. The ensure clarity to a reader the specification clearly defines the scope and meaning of semantic interpretation in the speech recognition grammar domain (Section 1.4).
Martin Duerst indicated he is " most probably okay" (see point 3).
From Martin Duerst
5) 2.1 Token: The section title seems inadequate. The section
should either speak only about single tokens, or the title
should be 'Token List' or something similar.
Resolution: Accepted
Title change to "Tokens".
From Martin Duerst
9) Many of the <pre> examples get cut when printed. This depends
very much on the device, but I would suggest an upper limit
of about 60 characters per line.
Resolution: Accepted
<pre> text is formatted to restrict page width.
From Martin Duerst
10) 2.3: the term 'legal rule expansion' is used here but not yet
defined.
Resolution: Accepted
The term 'legal rule expansion' is now formally defined at the start of Section 2 and appropriately hyperlinked when the term is used.
From Martin Duerst
11) 2.3: The matching is described multiple times in various very
different places and words. E.g.: 'expansions /must/ be spoken...',
'must be recognized in temporal sequence',...
Resolution: Accepted
Consistent terminology for matching has been applied to the specification.
From Martin Duerst
15) 3., second paragraph: 'the rulename resolution specification'
Is this a separate spec, or part of this spec?
Resolution: Accepted
The specification now clearly identifies the normative definition of rulename resolution. There was no change in the semantics of the specification but some editorial changes to call out the definition and link to it where appropriate.
From Susan Lesch
The title "Speech Recognition Grammar Specification for the W3C Speech Interface Framework" is pretty long, and there is no other reference to the W3C Speech Interface Framework in the spec. What about making the title "Speech Recognition Grammar Version 1.0" or "Speech Recognition Grammar Specification Version 1.0"?
Resolution: Accepted
Agreed! The specification name is now ""Speech Recognition Grammar Specification Version 1.0".
From Susan Lesch
There needs to be a References section, in place of links out of the running text to other documents and sites. Perhaps one is in the works?
Resolution: Accepted
Accepted. Appendix A now contains Normative (A.1) and Informative (A.2) references.
From Susan Lesch
For example domains, example.com is used in some cases, others not. mygrammars.com is used in 2.2.2, 2.2.5, and 4.5, acme.com in 6.6, and sayplease.com in A. grammars.com in 2.2.2 is registered, and opened numerous unwanted windows when visited on 14 January 2001. W3C recommends using example.com, example.org, and example.net; please see RFC 2606 section 3 at http://www.ietf.org/rfc/rfc2606.txt. If you need an evocative domain name, you could create a machine name, for example: grammars.example.org. Also, in 2.2.2, did you want the first domain in ABNF and XML to match?
Resolution: Accepted
All example URIs have been changed to example.com or grammar.example.com
From Susan Lesch
"#" is a "number sign" in Unicode. Variously, it is called a "fragment separator," "hash separator," and "pound" in this Working Draft. I would say "number sign (#)" globally except in the DTMF section where pound makes more sense. Please see http://www.unicode.org/charts/PDF/U0000.pdf. Some other characters are named below.
Resolution: Accepted
The '#' changes is now referenced as the "number sign" (correct name in Unicode) and description of its functional normalized to match RFC2396.
"pound" is the correct term for "#" button in US telephony. (There are other terms in other variants of English.)
From Susan Lesch
Below, a section number is followed by a quote and then a suggestion.
1. second to last par.
Examples
examples
Conformance
conformance
Future Study
future study
1. last par.
Standard
standard
1.1 par. 1
DTMF [spell out the first time]
Dual Tone Multi-Frequency (DTMF)
1.1 par. 2
through-out
throughout
1.1 last list item
Voice Browser
voice browser
1.2 par. 2 and 2.2.5
Speech Recognition N-Gram Grammar Specification
[should be a local anchor to [N-GRAM] in References]
1.2 par. 3
Dialog Markup Language or through a Speech Recognizer API.
Dialog Markup Language or through a speech recognizer API.
1.2 last list, item 2
may also includes
may also include
2.1 par. 1
aka, a terminal symbol
aka a terminal symbol
2.1 par. 2
white-space [twice]
white space
2.2 par. 1
Legal rule names must be legal XML IDs as defined in the
XML specification as the "Name" production in Section 2.3.
could read:
Rulenames must match "Name" as defined in XML 1.0 section
2.3 [XML] and be legal XML IDs.
2.2.2
a "$" symbol
a dollar sign ($) character
in a parentheses
in parentheses
2.2.3
short-hand
shorthand
the "$$" symbols
two dollar sign characters ($$)
2.2.5 par. 2
A speech recognizer may choose to support the Speech
Recognition N-Gram Grammar Specification in addition to
the Speech Recognition Grammar Specification defined in
this document.
could read:
A speech recognizer may choose to support the Speech
Recognition N-Gram Grammar Specification in addition to
the speech recognition grammar defined in this document.
2.6 ABNF
curly braces [five times]
curly brackets
2.7 ABNF
ISO8859-1
ISO-8859-1
2.8 ABNF list item 2
"[]"
"[]" square brackets
3.1 par. 1
The core purposes
The core purpose
3.1 ABNF
semi-colon
semicolon
3.2 par. 3
Java(TM) Programming Language
Java(TM) programming language
[see http://java.sun.com/docs/books/jls/]
4.2 par. 1
Locale
locale
4.4. par. 2
without a rulename identifier (applies both to
without a rulename identifier; (this applies both to
4.5 par. 2
Java Programming Language
Java programming language
5.4 par. 1
Grammar [three times]
grammar
5.4 Issues
shoud
should
5.6 par. 1
Grammar [three times]
grammar
6.1 last list item
principles outlined in Sec. 7 of W3C XSLT recommendation,
"Creating the result tree"
could read [not sure here]:
principles outlined in section 7 of the W3C XSLT Recommendation
[XSLT], "Creating the Result Tree"
CFG [please spell out]
Sec. 7.2, "creating text" of the XSLT specifications
[not sure here]
section 7.2 of the XSLT specification [XSLT], "Creating Text"
6.3 last list item
Voice Browser
voice browser
6.5 par. 2
for the Speech Synthesis Markup Language
[needs a link in References]
6.6
Lexicon Format
lexicon format
6.6 last par.
a Lexicon specification
a lexicon specification
6.7 par. 1
post-fix
postfix
curly braces
curly brackets
Appendix D par. 1
Normative
normative
Appendix D par. 2
Dual Tone Multiple Frequency
Dual Tone Multi-Frequency
[see
http://www.oreilly.com/reference/dictionary/terms/D/Dual_Tone_Multi-Frequency.htm]
Appendix D par. 4
commonally
commonly
Appendix D par. 6
post-fix
postfix
[1] http://www.w3.org/TR/2001/WD-speech-grammar-20010103/
Best wishes for your project,
--
Susan Lesch - mailto:lesch@w3.org tel:+1.858.483.4819
World Wide Web Consortium (W3C) - http://www.w3.org/
Resolution: Accepted
All typographical and other editorial changes applied as recommended.
From Laura Werner
Section 4.3, Pronunciation Lexicon:
In the example, lexicon looks like this:
lexicon $(http://www.example.com/lexicon.file);
However, in the EBNF grammar for ABNF, it says:
LexiconURI ::= '(' URIC+ ')'
One of these has to be wrong. I suspect it's the latter, because the rest
of the document consistently uses $(...)
Resolution: Accepted
The reviewer correctly identifies an inconsistency. The '$' should only be used as prefix to a rule reference in ABNF and should not have been present on a URI in a lexicon declaration. Fixed.
From Laura Werner
Appendix D, Formal Syntax for Augmented BNF
All of the URI tokens are defined using the URIC production from RFC2396,
e.g.
LexiconURI ::= '(' URIC+ ')'
However, since ')' is a valid character in URIC, this is nondeterministic.
Resolution: Accepted
The specification body did identify that ')' could appear within a URI and required that grammar authors use the '%29' URI escape to avoid ambiguity. However, this requirement was not reflected in the Formal ABNF definition.
In order to avoid ambiguity the Working Group changed the delimiters for URIs in the ABNF Form to '<' and '>'. Those characters are not legal within a URI.
From Martin Duerst
3) Conversion between ABNF and XML:
1.3: "character and entity declarations and references":
This summary description should be replaced by a list of the
actual constructs. The current wording gives the impression
that there are 'character declarations' in XML.
Resolution: Accepted
The offending language in Section 1.3 has been rectified.
From Martin Duerst
6) 'uri', 'grammarURI',...: These are correctly defined as
'anyURI' in the XML Schema (i.e. including non-ASCII characters),
but are otherwise directly related to RFC 2396 and 'URIC'
therein (excluding non-ASCII characters). The text has to
be clarified to make sure that 'anyURI's are allowed.
An actual example should be added.
Resolution: Accepted
A new 'Terminology' section of the specification (Section 1.6) defines URI by reference to 'anyURI' in the XML Schema Recommendation.
From Martin Duerst
7) 2.1, explanation of token syntax: 'tokens are delimited by
symbols ...': tokens, when unquoted, are defined as nmtoken
in the xml sense. While the explanation given may be reasonably
accurate for ASCII only, it is not a specification, and it
may lead to misunderstandings in other language/script contexts.
It should be clarified.
Resolution: Accepted
Section 2.1 defining Tokens and processor parsing of token regions defines clearly the parsing behavior.
From Martin Duerst
8) 2.7 Language and Locale: RFC 3066
The WD currently repeatedly speaks about using RFC 1766 instead
of RFC 3066 for language tags to be in line with XML. But XML
has been updated to use RFC 3066 by an erratum
(see http://www.w3.org/XML/xml-V10-2e-errata#E11). Please remove
any references to RFC 1766 and only reference RFC 3066.
Resolution: Accepted
Specification introduced 'language identifier' as a defined term. It is defined by reference to XML 1.0 language identification which in turn references RFC3066 (through Errata).
From Martin Duerst
9) 2.7 and elsewhere (in particular 4.1.2): The spec often speaks about
'language and locale' when talking about pure language issues. Please
remove all mentions of 'locale'. Please note that e.g. the 'us' in
in 'en-us' is not a locale, it is just a qualifier for the
language, resulting in 'English as spoken (or written in other
contexts) in the USA'.
Resolution: Accepted
All mention of 'locale' removed and replaced by 'language'.
From Martin Duerst
11) 2.8 should explain precedence of language tagging, and order
of language tagging and rep counts.
Resolution: Accepted
This oversight has been fixed by explicit definition of the precedence of language attachment and other postfix entities in the ABNF Form.
From Martin Duerst
12) 4.1: 'The first character of an ABNF document must be the "#"
symbol (x23)...': This strongly suggests that the spec was
written under the assumption that one character corresponds to
one byte. This is not the case, even for the string "ABNF",
in particular not for UTF-16.
Resolution: Accepted
The ABNF self-identifying header and character encoding detection (Section 4) now correctly define behavior for multi-byte encodings.
From Martin Duerst
13) 4.1: 'Newline handling follows XML conventions.": There are various
different conventions for newline handling in XML (e.g. element
content vs. attribute content, different attribute types,...).
Please be more specific.
Resolution: Accepted
The offending text was inaccurate and has been removed.
From Martin Duerst
14) 4.1.1 Character Encoding: The first paragraph is totally
confusing. 'symbol set' is not a term used in connection
with character encoding. Neither 'JIS' nor 'Unicode' are
character encodings. 'JIS' is also used wrongly in the
examples; the correct labels for the three most used
Japanese encodings are: 'iso-2022-jp', 'shift_jis', and
'euc-jp'.
Resolution: Accepted
The incorrect terminology regarding character encodings has been replaced. Correct IANA identifiers are used for example character encodings.
From Martin Duerst
4) 1.4 (and other places): "... the WG plans to require":
Requiring the use of another spec as of yet undefined or still
in the works by the current specification (which is in last
call) is really strange. Also, it does not seem adequate here;
the specifications are on purpose written independently and
so that other 'semantic interpretation' things can be used.
It is better to assure interoperability on a higher level,
e.g. by defining a profile or by just making all these
things W3C Recs.
Resolution: Accepted
All normative references in SRGS are now to IETF RFCs and W3C Recommendations. Some references to draft specifications remain but are informative only.
From Al Gilman
In the specification there is a remark to the effect -- quote A future draft of this specification will define semantic processing behavior. It is expected that white-space will be preserved in semantic results. -- end quote No. Don't even think about it. The web must not speak with a forked tongue. There has to be _one_ semantic model for whitespace in token declarations in speech recognition grammars. Or there is none. The speech processing semantics is that leading and trailing whitespace is not there, and contiguous sections of whitespace in the interior [that is to say appearing with non-whitespace both before and after it] is recognized at the "any whitespace is the same as any other whitespace" level of abstraction. That's the speech recognition behavior, that's the grammar language semantics. Point, paragraph, end of story. Processing that recognizes other distinctions is not 'semantic,' it is _amplifying noise_. I can't scream this loud enough. The semantics of a grammar encoded in this language is how it recognizes speech. That's all that will ever be checked, that's all one can reasonably expect to count on. Al Standard 'personal opinion' disclaimer applies. But I can explain [start with XMLGL, see previous message] why the 'disability interest' does care about the semantic integrity of our technology.
Resolution: Accepted
Working group was in full agreement that inconsistent white-space handling was not desirable. White-space handling is now clearly and consistently defined in the Token section (2.1) and other relevant document sections.
From Urquhart
A couple or three questions about the grammar spec : 1. Import resolution <import uri="http://www.somebody.org/grammars/grammar.xml" name="myref"/> This is clear <import uri="http://www.somebody.org/grammars/grammar.xml#rule" name="myref"/> In this case, does "myref" refer to the rule or its grammar? In other words, to use the rule, do I have to write : <ruleref import="myref#rule"/> or just <ruleref import="myref"/>? 2. Root rule "Implicit root rule ...... is equivalent to defining a rule with all the public rules alternatives" Does this imply that the weighting mechanisms in alternatives are also pertinent for public rules within the grammar? Can I weight public rules? 3. Referencing special rules I think this is just a typo, but there seems to be an inconsistency between the table in section 2.2 and the XML example in section 2.2.4. The table gives <ruleref special="#GARBAGE"/> and the example gives <ruleref special="GARBAGE"/>. I'm assuming it's the table that's correct ..... Answers much appreciated, Iain
Resolution: Acknowledged
Each of the comments applied to the January 3rd 2001 Last Call Working Draft of SRGS and had been addressed in the August 20th 2001 2nd Last Call Working Draft. No further action required.
From Laura Werner
I've just been looking over the ABNF part of the grammar working draft from
an implementation point of view, and I've come across a few minor issues:
Sections 4.2 - 4.4
Is there a good reason why the alias, lexicon, and meta declarations have to
come in that order? Requiring a specific order makes life harder for both
the implementer and the user, IMHO. I'm worried that users aren't going to
remember the proper order and are going to get very frustrated. And though
it's easy enough to implement an ABNF parser that requires the declarations
in this order, to make it usable I think I'll have to put in extra checks
for out-of-order declarations and issue intelligent error messages ("Meta
declarations must come after alias and lexicon declarations"). It would be
much easier to just allow them to come in any order. (Or to be mixed.)
Resolution: Accepted
Working Group applied what became known as the "loose headers" proposal.
In the ABNF Form of SRGS all header declarations must appear at the start of the document (after the self-identifying header but before the first rule definition) but there are no constraints on ordering of those declarations. This definition is reflected in the formal ABNF definition.
In the XML Form of SRGS most of the header declarations are attributes of the root <grammar> element and so the location is fixed. The remaining declarations (<lexicon>, <meta>, <metadata>) must appear before the rule definitions but in any order. The DTD and Schema reflect this definition.
From Laura Werner
Sections 4.1.2 - 4.1.5 I think the same argument applies to the language, mode, root, and tag-format declarations as well. It's a bit weaker, since you're only allowed to have one of each of these. But I'd much rather allow them to be specified in any order and enforce the one-of-each rule at at a semantic level.
Resolution: Accepted
Change accepted in applying the "loose headers" design summarized for GC05-1.
From Martin Duerst
1) The spec defines two formats, an XML-based and one that is not based
on XML. It was our understanding that W3C would not create/approve
any new unnecessary non-XML formats. XML has been carefully designed
to address basic internationalization issues (in particular character
encoding). Introducing other new formats seriously risks to put us
back into a situation that we had e.g. before RFC 2070. While we
may be able to avoid that for the specification itself, we cannot
afford the same effort as for XML for implementations and testing.
We therefore request you to remove the ABNF format from the specification.
Below, we also give comments on the ABNF format, but these are
mainly intended to show the problems and provide additional evidence
for why it should be removed.
Resolution: Rejected
The Voice Browser Working Group spent considerable time debating the merits and limitations of the ABNF Form of SRGS and whether it represents a reasonable alternative to the XML Form of SRGS. Special attention was given to the internationalization issue. The group consistently reached the following conclusions.
1. An XML specification is absolutely needed as the preferred means of representing speech recognition and DTMF grammars and inherits all the necessary internationalization features. The XML Form of SRGS is the recommended form for grammar authoring with the most demanding I18N needs.
2. The ABNF Form is prefered by many or most participants as the "human readable/authorable" form of grammars. This position is based on consistent feedback from developers of grammars working on current deployment of speech recognition. This user group indicated that BNF syntax is well-established in the speech recognition community. The syntax is compact, more familiar and thus more readable (to most, but not all, developers).
The Voice Browser Working Group put considerable effort into internationalizing ABNF (character encoding, byte order mark, careful terminology that recognizes the variety of linguistic and orthographic forms of languages, need for multi-lingual speech input, RFC3066). The VBWG recognizes, however, that it lacks some of I18N features of XML (e.g. character escaping, see GC08-4).
The VBWG and Internationalization Working Group met jointly at the W3C Cannes meeting. The I18N WG acknowledged that the VBWG had made a "cogent case for ABNF" and accepted the continued presence of ABNF. The VBWG committed to clarifying the limitations of ABNF wrt I18N.
From Martin Duerst
2) Conversion between ABNF and XML:
1.3 (also 2.1): "Whitespace cannot be preserved": This should be
explained in more detail, so that we can judge whether this affects
any languages. In many cases, even if whitespace processing looks
okay for languages based on the Latin script and similar scripts,
it may not work for other languages. In particular, if e.g.
some linebreak (optionally surrounded by other whitespace) is
introduced as part of pretty-printing for Japanese or Chinese,
and this linebreak is converted into just whitespace without
linebreaks in the conversion, then this may introduce a spurious
actual space in the final result. This should be checked carefully.
Resolution: Acknowledged
The specification is considered correct in that transformations between the XML Form and ABNF Form cannot automatically preserve pretty-printing because of the vastly different syntactic forms. This limitation of automatic transformation has been more clearly documented.
The description of transformation (Section 1.4) more clearly notes that semantically significant white space can and must be preserved in the transformation so that the transformed grammar is functionally equivalent to the original.
From Martin Duerst
10) It would be very nice if instead of 'lang-list', 'xml:lang'
could be used. The only problem with this is the multiple
language cases. How frequent are these in practice?
Resolution: Accepted
Replaced 'lang-list' by 'xml:lang' and documented the use of alternatives to create multi-lingual tokens.
From Martin Duerst
15) 4.1.1, 3rd para: 'the character encoding is optional':
It is only optional in some cases (please clarify),
and strongly recommended.
Resolution: Accepted
Note: the text should read "character encoding declaration". See GC08-19.
The specification fixed to explicitly define when the character encoding declaration is optional or required. For the XML Form the behavior must follow XML 1.0. For the ABNF Form the group choose to require the character encoding declaration be present whenever it would be required in XML 1.0 (same character encoding behavior). e.g. the declaration is optional for UTF-8 but required for EUC-KR.
From Martin Duerst
17) 4.4 defines <meta> and in particular http-equiv. At least
http-equiv should be removed, because its only major known actual
use is in connection with the 'charset' parameter, and this parameter
is covered both in abnf and in xml already.
Resolution: Rejected
VBWG determined that there are additional, important uses of 'http-equiv', for example, 'expires'. The 'http-equiv' declaration remains in both the ABNF and XML Forms of SRGS. Additional discussion led to clarification that 'http-equiv' declarations within a document take precedence over server-returned headers.
From Martin Duerst
6) 2.1: Defining empty tokens or tokens containing only space
as illegal seems completely unnecessary and only complicates
the spec. These cases should be defined as equivalent with
special='NULL'. Allowing ( ) or () further complicates
the issue unnecessarily.
Resolution: Accepted
Working Group agreed and removed these special definitions from the specification.
From Martin Duerst
7) Please use XLink syntax (xlink:href) instead of the 'uri' attribute.
Resolution: Dissent
The Working Group was unable to reach agreement with Martin Duerst on this matter. The following is a summary of the Working Group's analysis.
(1) A primary design requirement for SRGS is for the language to be utilized by VoiceXML 2.0 to represent XML grammars. More generally, the VBWG desires that all its specifications be consistent for developers.
(2) VoiceXML has several elements that have multiple URI attributes. However, XLink does not permit more than one URI attribute on a single element. Note that SRGS does not have any element with multiple URI attributes. Nevertheless, the VBWG was disposed to not introduce XLink into VoiceXML 2.0 and thus was biased against introducing XLink into any or all of its specifications including SRGS.
From Martin Duerst
8) 2.2.2: application/grammar+xml: The term 'grammar' seems much
too general here. Also, the spec says that this media type has
been requested, but I'm following the relevant IETF list and
do not remember such a request. Can you please provide a pointer
to the archive?
Resolution: Accepted
The Working Group agreed that the media type 'application/grammar' was too general. The WG has applied to the IETF for 'application/srgs+xml' for the XML Form and 'application/srgs' for the ABNF Form.
From Martin Duerst
9a) 2.2.4 Special rules: You should consider reserving some
rule names for future extension (e.g. all uppercase only names)
Resolution: Rejected
The working group decided that reserving all uppercase names would be too restrictive since grammars often use uppercase-only rulenames. The group did discuss whether reserving additional rulenames would be appropriate but did not identify other rulenames that we would like to reserve now. No changes were made to the specification.
Martin Duerst indicated he is " okay with the WG's decisions".
From Martin Duerst
12) 2.4: 'a set of alternatives must contain one or more alternatives':
Why not 'zero or more alternatives'? Zero would be equivalent to
special='VOID'. On the other hand, at the end of 2.4, the text
says that an empty <one-of> is allowed.
Resolution: Rejected
To ensure consistency with ABNF, which does not have a syntactic form that represents an empty alternative, an empty <one-of> is disallowed in XML grammars.
Martin Duerst indicated he is " okay with the WG's decision".
From Martin Duerst
13) 2.5, special case of <0> or <0-0>: Change the explanation to say
that this is the same as special='NULL'.
Resolution: Accepted
Change accepted as-is.
From Martin Duerst
14) There seems to be no need for both {!{ }!} and backslash escaping.
Please use only one mechanism, preferably backslash escaping.
Resolution: Accepted
The group agreed that having two escaping mechanisms was unnecessary.
Parallel work on Semantic Interpretation for Speech Recognition involves the use of an ECMAScript-like scripting language within tags which makes extensive use of curly braces. To simplify the developer experience the group determined that containing tags in
{!{ }!}is more elegant and easier to read than backslash escaping, as proposed in the reviewer comment.Martin Duerst indicated he is " okay with the WG's decision".
From Martin Duerst
16) 3.2 Scoping: The scoping rules are explained by reference to Java.
However, while there are very good reasons for data hiding and
therefore to have a default of 'private' in programming languages
such as Java, I can see absolutely no need for data hiding in
the case of speech grammar rules. There should be a better
explanation for why the default is 'private', or the default
should be changed to 'public' to make it easier to reuse rules.
Also, the rule that a private root can not be referenced by
name seems unmotivated.
Resolution: Rejected
Discussion that led to resolution started with a message from Andrew Hunt (Member Only). Analysis of scoping (all in favor) came from Paolo Baggia (Member Only), Dan Burnett (Member Only), Bruce Lucas and Luc Van Tichelen. Martin responded:
The spec I reviewed contained some reason, but looked very week to me. If the stronger reason(s) that people have discussed can replace the original text, I think than should work out well.The following informative guidance to grammar authors was added to the definition of scoping.
- Grammar authoring shares many properties of programming. Establishing contracts of an API is analogous to defining a set of grammars and defining the public rules of a grammar each with defined language behavior.
- Consistent design and implementation of public rules promotes grammar re-use and facilitates creation of grammar libraries.
- Natural language grammars often require creation of many internal "working" rules to create a smaller number of useful external rules. Hiding working rules with private scope allows revision of those rules without affecting other grammars that reference the grammar. Hiding working rules also prevents accidental mis-use of a working rule.
- Grammar compilation resembles programming language compilation. Making rules private allows advanced grammar compilers to perform optimizations that cannot be applied when a rule is declared public.
The issue was closed with this stronger statement on the use case for rule scoping.
From Martin Duerst
17) The choice of 'ABNF' as a magic number seems to be much to
general. (see above for application/grammar+xml). Similar
considerations apply to the chosen public identifier (and the
namespace), as well as the use of the term 'XML Grammar'
in the place of 'XML Speach Recognition Grammar'.
Resolution: Accepted-Rejected
The working group partially accepted and partially rejected this comment.
Accepted: The term 'XML Grammar' is no longer used in the specification. Inside it is referred to as the 'XML Form of the Speech Recognition Grammar Specification' or shortened to the 'XML Form' where the context is clear.
Accepted: the media type 'application/grammar+xml' was replaced by 'application/srgs+xml'. See GC09-8.
Rejected: the namespace and public identifier were not changed. The working group felt they were sufficiently qualified.
Martin Duerst indicated he is " okay with the WG's decision".
From Martin Duerst
18) 4.1.4: I think it would be a good idea to change
<grammar root="rulename" ...> to <grammar root="#rulename" ...>
Resolution: Rejected
The root attribute has type "IDREF" in the DTD and Schema and should not include the '#' character. The Working Group determined that type should not be changed as it provides a cheap document-local check of the validity of the attribute value.
Martin Duerst indicated he is " okay with the WG's decision".
From Martin Duerst
19) 4.1.5: Please use an URI as the identifier for 'semantic' tags.
Resolution: Accepted
Change accepted and applied to both the ABNF Form and XML Form.
From Martin Duerst
20) 2.2.2 and 4.2: It is a bad idea to have the media type specified
with the reference overwrite the media type determined from the
actual referenced resource.
Resolution: Dissent
Summary: The group did not make the change as proposed above by Martin Duerst. However, based on extensive discussion with Martin and within the group (summarized below) the specification was modified to highlight the limitations of declaring the type in a refering document and other actions were taken to ameliorate the concerns. Nevertheless the reviewer noted his objections to the final text and the group marks the issue as "Dissent".
The working group position was summarized in a response by Andrew Hunt to Martin Duerst. The following are the pertinent extracts:
Martin responds March 20, 2002:Your point that neither a resource specified by a URI, nor the bytes returned when resolving the URI, has a unique type, is well-taken. This means for example that a server is perfectly justified to return an HTTP header indicating a type of, say, text/plain, when the bytes are in fact also a valid W3C grammar. In such a case it's perfectly reasonable for the consumer of the resource to interpret those bytes (in a kind of casting operation) as some other type than the type indicated by the server, when the consumer of the resource has some "out-of-band" source of knowledge about the resource. The "type" attribute provides a way for an application developer to provide this "out-of-band" knowledge to the consumer (voice browser in this case). This is useful in the common case where the VoiceXML application developer is also in control of the bytes that the URI resolves to, but may not be in control of the type information returned by the server. This is especially important for new types, where experience shows web servers are frequently not configured to return the most useful or most specific type information for resources that conform to the new type. There is also precedent in recent W3C recommendations for such a "type" attribute: from the SMIL 2.0 Recommendation, Chapter 7 http://www.w3.org/TR/smil20/extended-media-object.html): The type attribute value takes precedence over other possible sources of the media type (for instance, the "Content-type" field in an HTTP exchange, or the file extension).I think the 'type' attribute may be a necessary fallback. But I think the main thrust of the spec and of the W3C should really be in getting the server side up to speed. This may include various things: - Making sure that the MIME type is actually registered. It's easier to convince a webmaster to add something to a config file if an author can point to a full registration, rather than just some 'customarily used' mime type. - Saying clearly in the spec that Web server configurations should be updated to send the right mime type. - Using contacts of the WG (and the W3C overall if necessary) to make sure the configurations in the newest releases of the servers are up to date. - Providing help on a public web page on how to set up various servers (see e.g. http://www.w3.org/International/O-HTTP-charset.html for an example; I'm glad to accept suggestions for improvement). - Ideally, combining the latent frustration about this issue in various WGs and Activities to some coordinated effort. If the WG can commit in some way to a number of the above issues, then that would be very good.[Media type registration] On the first point, the Working Group has submitted media type applications to IETF (see GC09-8) and included references to those applications in Appendix G of the Candidate Recommendation. See:
[1] Brad Porter, Steph Tryphonas: "The 'application/srgs' Media Type", IETF Internet-Draft, March 11, 2002. See http://www.ietf.org/internet-drafts/draft-porter-srgs-media-reg-00.txt
[2] Brad Porter, Steph Tryphonas: "The 'application/srgs+xml' Media Type", IETF Internet-Draft, March 11, 2002. See http://www.ietf.org/internet-drafts/draft-porter-srgsxml-media-reg-00.txt[Web server configuration] On the second point, the specification now states that use of the type attribute is recommended only when correct configuration of the web server is not possible.
[Web server software configuration] On the third point, the Working Group will defer any action until the IETF Media Type applications have been accepted or rejected.
[Help on server configuration] On the fourth point, the Working Group does not plan action to develop general educational material on web server configuration beyond stating clearly the media types and filename suffix conventions for SRGS.
[Escalation in W3C] On the fifth point, no action has been taken at this point beyond bring the issue to the attention of Philipp Hoschka (W3C Lead for the Interaction Domain).
At the minimum, I would like to see an explanation of the problems with using the type attribute on the link (a very clear example would be that somebody has some linked speech grammar files in ABNF, and converts them to the XML notation. All the type attributes in the links to that grammar fragment will have to be updated, which may be a real pain), and a commitment of the WG to (some of) the proposals for getting things improved on the server side.Andrew responded (May 9, 2002) to Martin to (1) summarize the spec changes regarding media type handling on rule references, (2) explain the disposition of each of Martin's requests, and (3) including the final text.
Al Gilman (WAI) responsed (May 10, 2002) indicating abstention on the draft language and agreement on the process being followed by the VBWG.
Martin responds June 5 indicating objection to the final changes made by the Working Group.
I'm sorry to be late in answering this. If still possible, I would indeed very much prefer that this be noted as a clear dissent. Looking at the text you currently have: >>>> ** Informative: use of the type attribute should be considered a last resort. For instance, the type may be appropriate when a grammar is fetched via HTTP but (1) a web server cannot be configured to indicate the correct media type, and (2) the grammar processor is unable to automatically detect the media type. In the event that a grammar is transformed to another form (e.g. ABNF Form to XML Form) then any type attribute on a reference to that grammar also must be modified. >>>> I have no idea how it would be easier to change all the 'type' attributes in all the references to a certain grammar, rather than to get the Content-Type of the referenced document in order. I agree that setting the Content-Type can be a problem on some servers, but it is a local problem that can be solved. Trying to assume that one can find all the documents that refer to a specific document, and change them at the same time, on the other hand, is 180 degrees against the scalability principles on the Web. For related discussion on server configuration, with very clear opinions that seem to confirm my point, please also see some recent TAG discussion at: http://lists.w3.org/Archives/Public/www-tag/2002Jun/0022.html Regards, Martin.Andrew responded on June 5 indicating that it felt had accomodated each of the specific actions requested by Martin. At this point the group determined to mark the issue as "Dissent".
W3C Director review of the Candidate Recommendation draft produced a request for modification of the media type definition. The Working Group modified the text so that in the circumstance that a protocol provides a media type (e.g. HTTP) that is not recognized by the grammar processor a the type of a grammar format, (e.g. web server fallback types such as text/plain or octet-stream), then the media type in the referring document is binding.
From Martin Duerst
21) RDF rather than the html-like ad-hoc <meta> should be used for
metadata.
Resolution: Accepted
A new
<metadata>attribute has been introduced to the XML Form of SRGS as a container for XML metadata. Specific reference is made to RDF and to the Dublin Core.Note that
<meta>is not deprecated. See also GC01-1 and GC08-17.
From Susan Lesch
Especially to help the conformance section, and also to be clear, you
could make RFC 2119 a normative reference and quote this part:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Please see RFC 2119 at http://www.ietf.org/rfc/rfc2119.txt. If you don't
wish to use this RFC, then these words probably need definitions.
Resolution: Accepted
RFC 2119 is normatively referenced and the appropriate verbiage introduced into the Conformance section.
From Al Gilman
The loose language inherited from the HTML tradition in the area of metadata is not the highest and best way to explain the metadata to be incorporated in grammar declaration documents. The 'author' field should be traceable to Dublin Core 'creator' by machinable relationships expressed in normative exhibits in this specification. See the discussion of schemas and tracing the sense of metastuff in http://www.w3.org/TR/xmlgl which is just out. See also the call for review at http://lists.w3.org/Archives/Public/w3c-wai-ig/2001JulSep/0604.html We, W3C, should be developing a metadata module for grammars, schemas, and all manner of metacode that reflects best current practice and 'exports the semantics' well. And speech grammar should use it, not re-invent or copy it. Al Disclaimer: These are individual remarks, despite any hats I may wear in WAI-PF. Have not been discussed among the group.
Resolution: Accepted
There were several threads of discussion of the metadata issue including those starting with the following messages:
http://lists.w3.org/Archives/Member/w3c-voice-wg/2002Mar/0008.html [W3C Member Only]
http://lists.w3.org/Archives/Member/w3c-wai-pf/2002JanMar/0309.html [W3C Member Only]
http://lists.w3.org/Archives/Member/w3c-wai-pf/2002JanMar/0303.html [W3C Member Only]
http://lists.w3.org/Archives/Member/w3c-wai-pf/2002AprJun/0103.html [W3C Member Only]From those threads and from several Voice Browser WG conference calls, including one in which Al Gilman participated, the following spec changes were made.
XML Metadata for XML Form Grammars
The Working Group introduced the
<metadata>element into the XML Form of SRGS to permit XML metadata containment within grammars. [Section 4.11.2] The specification recommends the Dublin Core but does not restrict other forms of XML metadata.XML Metadata within ABNF
The Working Group considered adding the ability to include XML metadata within an ABNF document but decided against because:
- Permitting containment of any XML content (metadata or other) within ABNF would require a new syntactic construct to ensure that the XML content is safely encapsulated. The existing commenting capability of ABNF was not considered safe (
/* */).- Even if XML metadata could be enclosed in an ABNF document there would be no existing utilities (e.g. spiders) that could automatically extract the metadata. The would make the metadata content far less useful than XML metadata within a XML document (perhaps useless without the special creation of special tools).
Referencing Separate XML Metadata Documents from ABNF or XML Grammars
The "seeAlso" meta property of Resource Description Framework (RDF) Schema Specification 1.0 [Section 2.3.4] is the only defined meta property for ABNF Form and XML Form grammars. It declares a reference to an external metadata document. See Section 4.11.1 of the SRGS.
This definition permits an ABNF and XML to consistently reference external XML metadata. It also permits transformation of aa XML Form grammar that contains inline XML metadata to an equivalent ABNF Form grammar with external metadata.
Other meta properties
The Last Call draft included a number of suggested meta properties (e.g. "author", "maintainer") that were consistent with VoiceXML and HTML but inconsistent with Dublin Core. Those 'ad hoc' properties have been deleted from the specification and replaced by a recommendation to use Dublin Core properties. All examples have been replaced with meta properties that use Dublin Core properties.
From Al Gilman
For speech recognition, one may wish to use as a token a phonetic equivalent of a word. This may be done by phonetic spelling in the ususal writing system of the current language, or by external-production-reference to a speech synthesis grammar production for a more precise phonetic form, if I understand the architecture. In any case, it is important to unambiguously capture the relationship to the standard spelling of a word, if the token represents a word. "The standard spelling" is meant to indicate "as you should look it up in a dictionary." There is an XML precedent in RUBY that could be followed for providing this capability. Is this planned to be covered in the 'semantic processing' volume? This is an important function. Please clarify. Al ["personal opinion" disclaimer] It is not clear that WAI can approve this document going to PR until that mechanism is defined and it is clear it works.
Resolution: Accepted
Introduced new language into Section 2.1 on tokens to provide guidance to developers on how to author grammars that may be used for both speech and non-speech input modalities. The non-speech input is important for certain classes of deployment that require broad accessibility.Grammar authors should consider the possibility that a grammar will be used to interpret input in a non-speech recognition device. For example, grammars can be used to process text strings from keyboard input, text telephone services, pen input and other text modalities. To facilitate text input a grammar should contain standard orthographic tokens of the language. That is, to facilitate non-speech recognition input the grammar should contain standard spellings of natural language words to the greatest extent possible.
From Martin Duerst
4) If the ABNF format is kept, a syntax for character escapes
(= numeric character references in XML) become necessary.
(see also http://www.w3.org/TR/charmod/#sec-Escaping)
Resolution: Rejected
At the W3C Cannes meeting (February 2002) the VBWG met with Martin Duerst and Misha Wolf of the Internationalization Working Group discussed this issue. The VBWG and I18N WG determined that character escapes will not be added to ABNF Form of SRGS. This limitation of the ABNF Form (compared to the XML Form) is documented in Section 4.4 of the specification (on character encoding). Reasoning is that the use case is limited, especially with the XML Form available for the most demanding I18N needs in grammar authoring.
From Martin Duerst
5) 'A future version ... may address ... case sensitivity ...'.
The draft does not currently say anything about how two strings
are compared. It should clearly say that it assumes early
uniform normalization (NFC, see
http://www.w3.org/TR/charmod/#sec-Normalization), or actually
that input must be checked for NFC. It also should clearly
say that strings are compared based on Unicode character
values. As for casing, it should probably say something like
that words should be used in their default casing.
Resolution: Accepted
The August 20 2001 LCWD was generally underspecified in the area of text handling and pronunciation lookup for speech recognition. The specification (Section 2.1) is now clear that recognizers may assume NFC and apply appropriate language-specific behavior (e.g. case handling) when resolving a token to a pronunciation.
From Martin Duerst
16) 4.1.1: If the abnf is kept, something parallel to Appendix
F of the XML rec seems necessary.
Resolution: Accepted
For ABNF Form, there is now defined behavior for auto-detection of single- vs. multi-byte encodings (including byte-order-mark) and big- vs. little-endian detection. The definition follows XML 1.0.