W3C

Speech Recognition Grammar Specification Version 1.0
2nd Last Call Disposition of Comments

June 20, 2002

Editors:
Andrew Hunt, SpeechWorks International
Scott McGlashan, PipeBeach

Abstract

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).

Status

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.

Table of Contents


1. Introduction

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.

2. Comments

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   

2.1 Clarifications, Typographical, and Other Editorial

Issue GC05-5

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.

Issue GC06-1

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.

Issue GC07-1

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.

Issue GC08-18

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.

Issue GC08-19

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".

Issue GC09-1

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.

Issue GC09-2

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.

Issue GC09-3

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).

Issue GC09-5

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".

Issue GC09-9

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.

Issue GC09-10

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.

Issue GC09-11

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.

Issue GC09-15

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.

Issue GC10-1

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".

Issue GC10-2

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.

Issue GC10-3

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

Issue GC10-4

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.)

Issue GC10-6

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.

2.2 Technical Errors

Issue GC05-3

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.

Issue GC05-4

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.

Issue GC08-3

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.

Issue GC08-6

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.

Issue GC08-7

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.

Issue GC08-8

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).

Issue GC08-9

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'.

Issue GC08-11

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.

Issue GC08-12

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.

Issue GC08-13

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.

Issue GC08-14

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.

Issue GC09-4

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.

2.3 Requests for Change to Existing Features

Issue GC03-1

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.

Issue GC04-1

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.

Issue GC05-1

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.

Issue GC05-2

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.

Issue GC08-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.

Issue GC08-2

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.

Issue GC08-10

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.

Issue GC08-15

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.

Issue GC08-17

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.

Issue GC09-6

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.

Issue GC09-7

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.

Issue GC09-8

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.

Issue GC09-9a

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".

Issue GC09-12

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".

Issue GC09-13

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.

Issue GC09-14

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".

Issue GC09-16

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.

Issue GC09-17

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".

Issue GC09-18

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".

Issue GC09-19

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.

Issue GC09-20

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:

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). 
Martin responds March 20, 2002:
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).

Martin adds March 20, 2002:

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.

Issue GC09-21

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.

Issue GC10-5

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.

2.4 Requests for New Feature

Issue GC01-1

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.

Issue GC02-1

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.

Issue GC08-4

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.

Issue GC08-5

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.

Issue GC08-16

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.