SRGF WD日本語版

1. はじめに
2. 規則拡張
3. 規則定義
4. 文法ドキュメント
5. 適合
6. 謝辞
付録A. ABNF形式とXML形式の文法の例
付録B. XML形式のためのDTD
付録C. XML文法形式のためのスキーマ
付録D. Augmented BNFのための形式上の構文
付録E. DTMF文法
付録F. XML文法をABNFに転換するためのXSLTスタイルシート
付録G. Media types and File Suffix
付録H. Logical Parse Structure
付録I. Features under Consideration fpr Future Versions

$Id: srgf.sdoc,v 1.8 2001/10/05 08:59:09 nishi Exp $

この文書はW3Cの公開する文書を独自に翻訳したものです。この仕様書の正式なものはW3Cのサイトにある英語版です。翻訳はまだ完成していません。また、多くの誤りがあることに留意してください。

正式な文書：Speech Recognition Grammar Specification for the W3C Speech Interface Framework, W3C Working Draft 20 August 2001(http://www.w3.org/TR/2001/WD-speech-grammar-20010820/)
日本語版作成：京都工芸繊維大学電子情報工学科パターン情報処理研究室
管理者：西本卓也, nishi@vox.dj.kit.ac.jp

1. はじめに

この文書では、文法表記のために構文を定義する。文法は開発者が音声認識器によって認識すべき単語と単語のパターンを指定することができるように、音声認識器と他の文法プロセッサによる使用を目的とする。

文法フォーマットの構文は2つの形式、拡張BNF（ABNF）構文とXML構文で示される。仕様書では、2つの表記が2つの形式の間で自動変換できるようにするために意味的にマップ可能であることを保証する。

拡張BNF構文（ABNF）：これは、この仕様書が参照しているJSpeech Grammar Formatを含む音声認識分野で、一般に使われる従来のBNF文法や多くの既存のBNFのような表記に類似しているプレーンテキスト（非XML）表記である。拡張BNFは、XMLとSGMLに関してDTDで使われる拡張BNFと混同されてはならない。
XML:この構文はXML要素を使用して文法構造を表現する。PipeBeach文法（W3Cメンバーのみ）とTalkML、そしてJSpeech Grammar Formatのresearch XML variantの設計を変更して取り入れている。

第2節、第3節と第4節では、ABNFとXML文法フォーマットを定義する。読者は、付録Aで仕様を理解するのに有益な例を見ることができる。第5節は、文法文書や音声認識器のような文法プロセッサのための適用基準を定義する。第6節では、W3C Voice Working Groupによって考えられている文法仕様のための将来研究における多くの問題を確認する。

このW3C Standardは、Speech Recognition Grammar Specificstionとして知られており、JSpeech Grammar Format(JSGF)上でモデル化されている。そしてそれは米国カリフォルニア州のSun Microsystems社によって認められている。

1.1. 文法プロセッサとユーザー・エージェント

文法プロセッサには、この仕様書で記述されるような入力文法を受け入れるものがいくつかある。

ユーザー・エージェントはユーザー入力を受け入れて、検出された入力に相当する認識結果を示すために文法とその入力を比べる文法プロセッサである。

仕様書タイトルが意味するように、音声認識器は文法プロセッサの重要なクラスである。この仕様書で使われている文法プロセッサのもう一つのクラスは、DTMF検出器（4.1.3節と付録Eを参照）である。ユーザー・エージェントによって受け入れられる入力タイプは、それが処理できる文法モードまたはモードによって決定される：例えば、音声は"voice"モード文法を入力とし、DTMFは"dtmf"モード文法を入力とする。

簡単にするために、この文書を通して音声認識器への参照が明確に述べられない限り、文法プロセッサの他のタイプに適用される。

音声認識器は、以下の入力と出力をもつユーザー・エージェントである：

Input：この仕様書で定義される1つの文法もしくは複数の文法。これらの文法は、認識すべき単語と単語のパターンを認識器に知らせる。
Input：文法(複数の文法)にマッチする音声内容を含む連続音声。
Output：音声認識器によって検出される音声内容についての詳細を示す結果の記述。結果の内容を示すフォーマットと詳細は、この仕様書の範囲外である。有益な目的のために、大部分の実質的な認識器には少なくともいくつかの検出された単語の転写を含んでる。
Output：エラーとその他の動作情報は、ホスト環境に示される。：例えば、文法プロセッサを統合するVoice Browserなど。ホスト環境に対する相互作用の方法は、この文書の範囲外である。しかしながら、仕様書ではconformantな文法プロセッサが文法文書の解析や他の処理におけるエラー環境を知らせることを義務づけている。

1.2. 範囲

音声認識器文法の主要な使用法は、認識器が何を認識すべきかについて具体的に示すことを音声アプリケーションに許すことである：

話される単語
それらの単語が生じるパターン
口語的単語の言葉

多くの音声認識器も、音声認識N-Gram文法仕様をサポートしている。2つの仕様書では口語的な入力を検出するための音声認識器セットアップ法を定義しているが、異なった相補的な方法で単語と単語のパターンを定義している。一部の認識器では、2つのフォーマットで文法間の相互参照を許している。この仕様書の規則参照要素では、N-gram文書の参照方法を記述する。

文法仕様では、音声認識の動作に影響を及ぼす多くの他の問題には対処しない。大部分の次の機能では文法が参照される、もしくは呼び出される前後関係によって対処される：例えば、対話Markup言語または音声認識器APIによって。

話者適合データ：一部の音声認識器は話者の声に動的に適応するための機能をサポートし、そして多くのものは後の使用に備えてその声の適合データを蓄えておく機能もサポートしている。話者データには、ユーザーによってよく話される単語のリストも含まれる。文法フォーマットは、これらの機能に対して明確に対処しない。
音声認識器構成：文法フォーマットはタイムアウト、認識閾値、検索サイズ、もしくはN-best結果カウントのような認識器機能をセットするための機能を含んでいない。
語彙：文法フォーマットは、文法によって参照される語彙の積載、または単語の発音に対処しない。W3C Voice Browser Working Groupは標準の語彙フォーマットの開発を考慮している。もしフォーマットが開発された時は、適切な更新がこの文法仕様に対してなされる。

1.3. 文法変換

ABNF形式、XML形式の2つの表現が意味的にマップ可能なことを保証するために指定された。文法の意味的の動作が等価であるならば、自動的にABNF文法をXML文法（または逆）に変換することが可能でなければならない。意味的な動作の等価性について次に示す：

両文法は、入力として同じ言語を受け入れて、同じ言語を受け入れない。
両文法は、どんな入力ストリングでも同様に解析する。

付録FのXSL変換文書は、XMLからABNFへの自動変換を示す。逆変換には、ABNFパーサーと変換プログラムを必要とする。

ABNF形式からXML形式への自動変換には固有の制限がある。

空白は保存されない。
XML構造にはABNFで等価のものがないものがある：DTD、キャラクタ、存在宣言、存在参照、処理命令、namespace。キャラクタと存在参照はABNFへの変換に拡張されるが、他の構造は失われる。
文法構造に関して順序づけているコメントは修正される。

問題：存在参照に関する上記の文が、仕様書の中でXML存在に関する唯一の文であるということである。XML文法プロセッサは5.4節の適用資格が与えられるであろういくつかのXMLプロセッサとして、全てのXML存在を処理しなればならないと仮定される。以降の草案において、この問題はより効果的に文書化されなければならない。

1.4. 意味解釈

W3C Voice Browser Working Groupは、現在"音声認識のための意味解釈"の仕様書を作っている。今度の仕様では、意味結果において文法タグの内容と口語的もしくはそうでない入力の変換のための言語を定義する。

文法のポータビリティを保証するために、Working Groupは全ての対応する文法プロセッサが文法対応要求とともにW3C意味タグ仕様をサポートしなければならないようにしようと計画している。

読者は、この文書の中の単純なタグ例が意味タグ仕様の方向性を示すと仮定してはならない。"音声認識のための意味解釈"の仕様の最初の動作草案が公表されれば、例は更新される。

2. 規則拡張

規則拡張は、トークンのパターンと規則参照そしてこれらの組み合わせを定義する標準的な表現である。

2.1：トークン
2.2：規則参照
2.3：シーケンス
2.4：選択肢
2.5：繰り返し
2.6：タグ
2.7：言語と場所
2.8：優先順位

2.1. トークン

トークン（いわゆる終端記号）は、口語的である単語やその他の存在を定義する文法の一部である。XMLとABNF両形式でのどんな特徴がないテキストでも、トークンである。

文法フォーマットでは、トークンが語彙入力として分析されて、認識器によって発音を結びつけられる。文法設計者は、明らかな発音を持たないトークンのキャラクタと形式を防止することによって文書ポータビリティを改善することができる。例えば、英語で句読点がトークンの範囲内で使われてはならないが、その代わりに"spelled"バージョンでは使われなければならない："ampersand"もしくは"and"、としての"&"；"plus"としての"+"；"less than"もしくは"open angle branket"、として"<"；など。文法プロセッサは、桁（例えば、ヨーロッパのスクリプトのための"0"から"9"）をサポートしなければならないが、トークンとして自然数（例えば、"10"、"1000"、"4324"、"3.1415"）をサポートしなくてよい。

ABNFとXML両形式は、空白か他の特別なシンボルを含むトークンを許すために提示されるトークンを許す。トークンを比較するとき、空白は保存されない。提示されたトークンの中で続けて存在する空白は無視される。まるで一つの"スペース"キャラクタ（#x20）のみが存在したかのように、どんなトークン内部の空白でも1つとして扱われる。したがって、以下は全て等価トークンである：

 
	"San Francisco"
	" San Francisco "
	"San 
	Francisco"
	"   San    Francisco    "

トークンの範囲内の空白の存在が有意であるので、以下は異なったトークンである。

 
	"San Francisco"
	"SanFrancisco"
	"San_Francisco"

この仕様書の今後の草案では、意味処理動作を定義する。空白は意味結果において保存されるであろう。

この仕様の今後のバージョンでは、事例感度と他のストリング比較動作を含むより複雑な語彙検索問題に対処する。

ABNF形式

どんなプレーンテキストでも、トークンである。トークンは、空白または特別なシンタックスの機能であるシンボルによって区切られる（例えば；= | * + <>（）[ ]　{}　/* */　//）。もしトークンが空白または特別なシンボルを含むならば、はっきりと提示される。トークンのための言語マーカー（US Englishと下記に示された）は、2.7節で定義される。

 
	hello
	bon voyage
	this is a test    // sequence of four tokens
	"San Francisco"
	("San Francisco")!en-US
	2

特殊なケース

空のトークンまたは空白だけのトークンは不当である。

 
	// Illegal
	""
	"   "

XML形式

引用の同じ使用を含むABNFトークンと同じスタイルである。XML区切り文字は、トークン区切り文字の働きをする。

提示しているトークンに代わるものとして、XML形式ではトークンは"トークン"要素ではっきりと区切られる。要素の内容は、一つのトークンに相当しているPCDATAである。2.7節では、言語または拡張言語を示している「lang-リスト」属性の使用を定義する。

 
	hello
	bon voyage
	this is a test    (sequence of four tokens)
	"San Francisco"
	<token lang-list="en-US">San Francisco</token>

	2

特殊なケース

空のトークンまたは空白だけのトークンは不当である。空のトークン要素または空白だけのトークン要素は不当である。

 
	// Illegal
	""
	"   "
	<token/>
	<token></token>
	<token>  </token>

2.2. 規則参照

規則名:すべての規則定義は、それが定義される文法の範囲内で一意でなければならないローカルな名前を持つ。正当な規則名は、2.3節での"Name"プロダクションと同様にXML仕様において定義される正当なXMLIDsでなければならない。3.1節では、規則定義メカニズムと規則の正当な命名法を文書化する。

この表は、文法文書の至る所で可能である規則参照のさまざまな形式がまとめてある。

参照タイプ	ABNF形式	XML形式
2.2.1：ローカルな規則参照	$rulename	<ruleref uri="#rulename"/>
2.2.2：URIによって同定される文法の命名された規則の参照	$(grammarURI#rulename)	<ruleref uri="grammarURI#rulename"/>
2.2.2：URIによって同定される文法のルート規則の参照	$(grammarURI)	<ruleref uri="grammarURI"/>
2.2.2：メディア・タイプとURIによって同定される文法の命名された規則の参照	$(grammarURI#rulename)~(mime-type)	<ruleref uri="grammarURI#rulename" type="mime-type"/>
2.2.2：メディア・タイプとURIによって同定される文法のルート規則の参照	$(grammarURI)~(mime-type)	<ruleref uri="grammarURI" type="mime-type"/>
2.2.3：URIエイリアスによって同定される文法の命名された規則の参照	$$aliasname#rulename	<ruleref alias="aliasname#rulename"/>
2.2.3：URIエイリアスによって同定される文法のルート規則の参照	$$aliasname	<ruleref alias="aliasname"/>
2.2.4:特殊な規則定義	$NULL $VOID $GARBAGE	<ruleref special="NULL"/> <ruleref special="VOID"/> <ruleref special="GARBAGE"/>

2.2.1. ローカル参照

参照する規則がローカルに定義される（参照を含むような同じ文法において定義される）とき、常にローカルな規則名だけから成る単純な規則名参照を使わなければならない。ABNF形式とXML形式は、単純な規則名参照に相当する異なる構文を持つ。

ABNF形式

単純な規則名参照には、"$"キャラクタを前に置く。

 
	$city
	$digit

XML形式

"ruleref"要素は、フラグメントとして規則参照を指定する"uri"属性での空の要素である。

 
	<ruleref uri="#city"/>
	<ruleref uri="#digit"/>

2.2.2. URIによる外部参照

他の文法において定義される規則参照は、3節で定義される条件の下で正当である。外部参照は、外部文法を同定しなければならず、その文法の範囲内で特定の規則を同定する。規則名フラグメントが省略されるならば、参照は外部文法の"ルート"規則を目標とする。

URI参照には、任意に文法のメディア・タイプの表示が付いてくる。もし省略されるならば、文法タイプは他の手段（例えばhttpヘッダ）で決定される。

参照する文書と参照される文書が異なるモードを持つならば、URI参照は不当である。たとえば、"voice"文法から"dtmf"文法に参照することは、不当である。（モードに関する新たな詳細については4.1.3節参照。）

ABNF文法とXML文法に対するメディア・タイプの状態の概要については付録Gを参照。

参照する文書のメディア・タイプが参照される文法のメディア・タイプと一致していないとき、他の手段（例えば参照される文法のhttpヘッダまたは宣言）で決定されたとき、今後の草案では文法プロセッサの動作を指定しなければならない。

ABNF形式

外部文法のためのURLとオプションの規則名フラグメントは、"$"シンボルの後に括弧で囲まれる。

 
	// References to specific rules of an external grammar
	$(http://www.mygrammars.com/world-cities.gram#canada)
	$(http://www.example.com/numbers.gram#digit)

	// Reference to the root rule of an external grammar
	$(../date.gram)

メディア・タイプが指定されるならば、それは括弧によって区切られて、（空白をはさまずに）"~"シンボルの後でURIにすぐ添付される。

Note："application/grammar"のメディア・タイプは、ABNFのために要求されるが、まだ与えられない。詳細は付録Gを参照。

 
	// References with associated media types
	$(http://www.mygrammars.com/world-cities.gram#canada)~(application/grammar)
	$(../date.gram)~(application/grammar)

問題：開いた括弧 '(' と閉じた括弧 ')' シンボルが、URIでは両方とも許されるが、$(uri)構造で ')' エラーを含むことは、現在構文エラーである。文法立案者は、RFC 1630においてURIのために定義される標準のパーセント脱出構文を用いて、この制限下でも動くようにした。つまりURIの範囲内で '(' と ')'シンボルをそれぞれ '%28' と '%29' に置き換えた。今後の草案では、異なるURI区切り文字キャラクタを採用することとする。

XML形式

"ruleref"要素は、フラグメントとして任意に規則参照を指定する"uri"属性での空の要素である。

 
	<!-- References to specific rules of an external grammar -->
	<ruleref uri="http://www.grammars.com/world-cities.xml#canada"/>
	<ruleref uri="http://www.example.com/numbers.xml#digit"/>

	<!-- Reference to the root rule of an external grammar -->
	<ruleref uri="../date.gram"/>

任意の"type"属性は、参照を含んでいる文法のメディア・タイプを指定する。

Note: "application/grammar+xml"のメディア・タイプは、XML文法のために要求されるが、まだ与えられない。文法のためのメディア・タイプに関する詳細については付録Gを参照。

 
	<!-- References with associated media types -->
	<ruleref uri="http://www.grammars.com/world-cities.xml#canada"
type="application/grammar+xml"/>
	<ruleref uri="../date.xml" type="application/grammar+xml"/>

2.2.3. エイリアスによる外部参照

4.2節では、エイリアス宣言を定義する。エイリアスは、外部文法のローカルな名前を定義する。外部文法は、そのURIによって同定される。規則参照構文は、エイリアス名による文法の規則参照をサポートするために特別なメカニズムを持つ。

URIによる参照と同様に、参照は文法名を同定しなければならず、その文法の範囲内で定義される規則の名前を任意に指定する。もし規則名が省略されたら、文法のルート規則が参照される。

もし参照する文書と参照される文書が異なるモードを持つならば、エイリアスは不当である。例えば、"voice"文法の中で"dtmf"文法のためのエイリアスをつくることは不当である。（モードに関する新たな詳細については4.1.3節を参照。）

ABNF形式

エイリアスによる参照は、エイリアス名と任意にフラグメント・セパレーター"#"、参照された文法の範囲内の規則名が続く参照を示すための"$$"シンボルから成る。

 
	// Reference a specific rule of the grammar identified by the URI alias 
$$places#city

	// Reference the root rule of the grammar identified by the URI alias 
$$places

XML形式

"uri"属性の代わりに、エイリアス属性が特別な構文（フラグメントでURIのように見せる）で使われる。エイリアス属性の値は、任意にハッシュ・セパレーター"#"とそれから参照される文法の範囲内の規則名が続くエイリアス名である。

 
	<!-- Reference a specific rule of the grammar referenced by the alias  -->
	<ruleref alias="places#city"/>


	<!-- Reference the root rule of the grammar referenced by the alias  -->
	<ruleref alias="places"/>

2.2.4. 特別規則

いくつかの規則名が、音声認識器による特定の解釈と処理を可能にするために定義される。文法は、これらの規則名を再定義してはならない。

$NULL <ruleref special="NULL"/>

自動的にマッチさせる規則を定義する：すなわちユーザが話しているどんな単語にもマッチする。
$VOID <ruleref special="VOID"/>

決して話されない規則を定義する。シーケンスの中にVOIDを挿入することによって、自動的にそのシーケンスを言葉に表せなくする。
$GARBAGE <ruleref special="GARBAGE"/>

次の規則がマッチするまで、あるいは次のトークン、口語入力の終わりまでにあるどんな言葉でもマッチさせる規則を定義する。例えば、米国の都市と州の所定の定義として作成した以下のABNFとXMLの規則定義は、単なる"Philadelphia Pennsylvania"と同様に"Philadelphia in the great state of Pennsylvania"にもマッチする。

 
	$location = $city $GARBAGE $state;

 
	<rule id="location">
	  <ruleref uri="#city"/>
	  <ruleref special="GARBAGE"/>
	  <ruleref uri="#state"/>
	</rule>

2.2.5. N-gram文書を参照する

Voice Browser Working Groupは、この仕様書と平行してStochastic言語モデル(N-Gram)仕様のための動作草案も発表した。これらの2つの仕様は、認識すべき単語そして単語のパターンを音声認識器に知らせるための異なる補完的な方法に相当する。

音声認識器は、この文書において定義される音声認識文法仕様に加えて、音声認識N-Gram文法仕様もサポートすることにする。

音声認識器が両方の文法表記をサポートするならば、それは任意に2つのフォーマットの間での参照をサポートしなければならない。ABNFフォーマットまたはXMLフォーマットで定義される文法は、N-Gram文書とその逆のスタート・シンボルを参照する。

N-Gramを参照するための構文は、外部定義されたABNF文法文書またはXML文法文書を参照するのと同じものである。URI参照とエイリアスの両方を参照する方法は、ABNFとXML両形式で可能である。メディア・タイプは、N-gram文書での参照に関して可能である。Working GroupはN-gram文書の上でのタイプをまだ導入していないので、例は挙げられない。フラグメント識別子（ABNF文法とXML文法を参照する時の規則名）はN-Gram仕様によって定義されるようにスタート・シンボルを同定する。スタート・シンボルがないならば、N-Gram仕様において定義されるように、N-Gram全体が参照される。

ABNF形式

N-Gram文書へのURI参照とエイリアス参照は、他のABNF/XML文法文書への参照と同じ構文に従う。以下は、明確な規則参照とルート規則への参照でのURI参照とエイリアス参照の例である。

 
	$(http://www.mygrammars.com/ngram.xml#StartSymbol)
	$(http://www.mygrammars.com/ngram.xml)
	$$ngram#StartSymbol
	$$ngram

XML形式

 
	<ruleref uri="http://www.mygrammars.com/ngram.xml#StartSymbol"/>
	<ruleref uri="http://www.mygrammars.com/ngram.xml"/>
	<ruleref alias="ngram#StartSymbol"/>
	<ruleref alias="ngram"/>

2.3. シーケンス

正当な規則拡張シーケンスは、それ自身で正当な規則拡張である。

文法の中の規則拡張シーケンスは、拡張がユーザーによって話され、音声認識器によって検出されなければならないという時間的命令を意味する。この制約は、トークンシーケンス、規則参照シーケンス、タグシーケンス、括弧そしてこれらの規則拡張の全ての組合せに適用される。

ABNF形式

正当な拡張シーケンスは、連結されたsub-expansionsの空白分離されたストリングである。必要な場合、シーケンスは括弧で初めと終わりを区切られる。

 
	this is a test           // sequence of tokens
	$action $object          // sequence of rule references
	the $object is $color    // sequence of tokens and rule references
	(fly to $city)           // parentheses for explicit boundaries

特殊なケース

空の括弧は正当なので、空白だけ含んでいる括弧が存在する；例えば、"()"、"(　)"。両方の形式は$NULLと等価である。そして、まるで括弧は存在しないかのように、文法プロセッサは動作する。

 
	// equivalent sequences
	phone home
	phone ( ) home

XML形式

XML規則拡張要素（<ruleref>、<item>、<one-of>、<token> <tag>）のシーケンスと空白分離されたトークンを含んでいるCDATA節は、時間的シーケンスで認識されなければならない。（唯一の例外は、一つ以上の"item"要素が"one-of"要素の範囲内に現れるところである。）

必要に応じて、"item"要素は、繰り返し属性が付与されるのを可能にするためにシーケンスの要素を囲むことができる。"item"の"weight"属性は、要素が"one-of"要素の範囲内に現れない限り無視される。

 
	<!-- sequence of tokens -->
	this is a test

	<!--sequence of rule references-->
	<ruleref uri="#action"/> <ruleref uri="#object"/>

	<!--sequence of tokens and rule references-->
	the <ruleref uri="#object"/> is <ruleref uri="#color"/>

	<!-- sequence container -->
	<item>fly to <ruleref uri="#city"/> </item>

特殊なケース

空のアイテム要素は正当なので、空白だけを含んでいるアイテム要素が存在する。両方の形式はNULL参照と等価である。そして、まるでアイテムが存在しないかのように、文法プロセッサは動作する。

 
	// equivalent sequences
	phone home
	phone <item/> home
	phone <item></item> home
	phone <item>    </item> home

2.4. 選択肢

選択肢規則拡張の集合は、それ自身で正当な規則拡張である。入力が選択肢規則拡張の集合にマッチするためには、選択肢拡張の集合のうちの1つにマッチしなければならない。選択肢の集合は、1つ以上の選択肢を含まなければならない。

2.4.1. 重み

重みは、それぞれの選択肢拡張に対して任意に与えられる。重みは、単純な正浮動小数点値（"nnn"、".nnn"、"nnn.nnn"）である。以下のどの場合で重みを選択肢に与えても、正当である：

すべての選択肢に正当な重みがある選択肢の集合
重みがない選択肢の集合
全ての選択肢にではないが、1つまたは多数の正当な重みがある選択肢の集合
重みがある1つの選択肢
重みがない1つの選択肢

重みというのは名目上、音声認識検索の検索領域を拡大している原因である。以下は、音声認識技術というテーマ、そして重みが適用される基本的な統計フレームワークに関してためになる参考文献である。

音声認識のための統計的な方法、Frederic Jelinek、ISBN：0-262-10066-5（1998）
音声認識の基礎

検索領域を拡大している要因であるという重みの定義から以下のことが言える：

"1.0"という重みは、音声認識結果に対して何ら影響を及ぼさない。
"1.0"より大きい重みは、それが付与される選択肢に肯定的なバイアスをかける。（たとえ重みがなかったとしても、それは認識されそうでなければならない。）
"1.0"未満の重みは、それが付与される選択肢に否定的なバイアスをかける。（たとえ重みがなかったとしても、それはあまり認識されなさそうでなくてはならない。）
"0.0"の重みは、その選択肢が決してマッチしないということを意味する。

もしも選択肢の重みが指定されなければ、そのデフォルト値は"1.0"である。（デフォルトの重みが音声認識に対して何の影響も持たないことは上記から分かる。）

文法立案者と音声認識器開発者は、上記で概説されたような重みの定義とアプリケーションに対する以下の制限を知っていなければならない。

音声認識検索に対する重みのアプリケーションは、認識器の内部制御下にある。重みを与えるための規範的もしくは有益なアルゴリズムは存在しない。さらに、音声認識とは一貫した動作が保証されないような統計処理である。
いくつかの特定の文法と認識器に対して、適切な重みを決定することは難しい。重みを推測することによって、必ずしも音声認識性能が向上するわけではない。
有益な重みを得る最も良い方法は、その文法に対する実質的な音声入力の研究をすることである。例えば、ポータブルな重みを発見するための合理的なテクニックは、選択肢の集合の出現回数と関連がある重みを使うことである。
特定の認識器のために重みを調整することは、他の音声認識器での認識性能の向上を保証するものではない。

上記で挙げられている制限にもかかわらず、この文書の作成者は大多数の文法と音声認識器にとって重みの合理的な共通操作が可能であると考えている。我々は、次のように合理的な共通操作を定義する。

認識器Aのためにつくられた重みを含む文法Gを考える。全ての重みを考えないということを除いては、文法Gと同一であるような文法G'を作る。文法G'より文法Gの方が認識器Xにおいてより良い性能を達成すると仮定する。文法Gは、大多数の類似の認識器（言語、サポートされた文法サイズ、などに関して類似した）にとって合理的で操作が共通であると言われる。文法Gは少なくとも文法G'と同様またはよりよい機能を持っている。

調整された文法が合理的で操作が共通でない認識器は、この標準に実装される文法のポータビリティを弱めないために非標準重み定義構文を使わなければならない。

ABNF形式

選択肢の集合は垂直バーシンボルで区切られた正当な拡張リストとして表わされる。必要であるならば、選択肢の集合は括弧によって区切られる。

 
	Michael | Yuriko | Mary | Duke | $otherNames
	(1 | 2 | 3)

重みは、スラッシュによって囲まれて、選択肢リストの中のそれぞれのアイテムの前に置かれる。

 
	// Weight above 1.0 is a positive bias
	// Weight below 1.0 is a negative bias
	// Default is 1.0 which does not affect recognition
	/10/ small | /2/ medium |  large
	/3.1415/ pie | /1.414/ root beer | /.25/ cola

特殊なケース

選択肢として、$NULL、空の括弧または1つのタグの参照があっても良い。それぞれのケースにおいて、入力は$NULLにマッチする。そして結果として他の選択肢は任意である。

 
	// Legal
	$rule1 = word | $NULL;
	$rule2 = () | word;
	$rule3 = word | {tag};

空の選択肢（空白だけ）は、正当でない。

 
	// ILLEGAL
	$rule1 = a | | b;
	$rule2 = | b;
	$rule3 = a |;

以下の構造は、1だけ重み付けされた選択肢と解釈される。

 
	// Legal
	$rule1 = /2/ word;
	$rule2 = /2/ {tag};
	$rule3 = /2/ $NULL;

XML形式

"one-of"要素は、選択肢要素の集合を同定する。それぞれの選択肢拡張は、"item"要素に含まれる。重みは、"item"要素の"weight"属性によって任意に示される。

 
	<one-of>
	  <item>Michael</item>
	  <item>Yuriko</item>
	  <item>Mary</item>
	  <item>Duke</item>
	  <item><ruleref uri="#otherNames"/></item>
	</one-of>

	<one-of><item>1</item> <item>2</item> <item>3</item></one-of>

	<one-of>
	  <item weight="10">small</item>
	  <item weight="2">medium</item>
	  <!-- Default weight is "1.0" -->
	  <item >large</item>
	</one-of>

	<one-of>
	  <!-- Weights above 1.0 are positive bias -->
	  <item weight="3.1415">pie</item>
	  <item weight="1.414">root beer</item>
	  <!-- Weights below 1.0 are negative bias -->
	  <item weight=".25">cola</item>
	</one-of>

特殊なケース

1つのアイテムを含んでいるone-of要素は正当で、そのアイテムにマッチする入力が必要である。そのアイテムには、任意に重みを付加できる。

 
	<one-of>
	  <item>word</item>
	</one-of>

	<one-of>
	  <item weight="2.0">word</item>
	</one-of>

アイテムを含んでいないone-of要素は正当であるが、特殊なVOID規則に等しい?すなわち、one-of要素は、ユーザー入力によって決してマッチさせることができない。ABNFに等価表記が存在しない。

選択肢としてのNULL、空のアイテムまたは1つのタグの参照は正当である。それぞれのケースにおいて、入力はNULLにマッチする。そして結果として他の選択肢は任意である。

 
	<one-of>
	  <item>word</item>
	  <item/>
	</one-of>
	<one-of>
	  <item>word</item>
	  <item> <ruleref special="$NULL"/> </item>
	</one-of>
	<one-of>
	  <item>word</item>
	  <item> <tag>content</tag> </item>
	</one-of>

2.5. 繰り返し

任意の回数、0回以上繰り返される、1回以上繰り返される、もしくはいくつかの範囲で繰り返されるもうひとつのsub-expamsionのような正当な規則拡張を定義する演算子が提供される。

ABNF形式の例	XML形式の例	動作
<n> <6>	repeat="n" repeat="6"	含まれた拡張は、"n"回正確に繰り返される。"n"は、"0"または正の整数でなければならない。
<m-n> <4-6>	repeat="m-n" repeat="4-6"	含まれた拡張は、"m"と"n"（含んでいる）の差の回数だけ繰り返される。"m"と"n"は両方とも"0"または正整数でなければならない。そして、"m"は"n"以下でなければならない。
<m-> <3->	repeat="m-" repeat="3-"	含まれた拡張は、"m"回もしくはそれ以上（含んでいる）繰り返される。"m"は、"0"または正整数でなければならない。例えば、"3-"は含まれた拡張が3回、4回、5回もしくはそれ以上生じるということを宣言する。
<0-1> [...]	repeat="0-1"	含まれた拡張は、任意の回数繰り返される。

一般的な繰り返し

上記の表で示されているように、0-1回生じるという時の拡張は任意である。任意性がそのような一般的な形式であるので、ABNF構文では任意性を表わす特別な演算子として四角括弧に入れるようにする。

"0-"の繰り返しは、拡張が0回、1回もしくは何回でも生じるということを示している。規則的な表現言語では、これはKleene star('*')でよく表わされるがABNFでは使われない。

"1-"の繰り返しは、拡張が1回またはそれ以上生じるということを示す。規則的な表現言語では、これは正の記号('+')でよく表わされる。ABNFではあるけど使われない。

ABNFとXMLの両方とも無限数の入力トークンを許す文法をサポートしているけれども、ユーザが無期限に話しつづけるということはありえない。立案者が繰り返しの発生に関してより限られた範囲を示したら、音声認識はより効果的に実行することができる。

繰り返し確率

いくつかの繰り返し演算子は、任意の繰り返し確率を指定する。その値は、繰り返された拡張の連続した反復の確率を示す。値は"0.0"から"1.0"（含んでいる）の浮動小数点範囲になければならない。この範囲外の値は、エラーである。浮動小数点フォーマットは、"n"、"n.nnnn"、".nnnn"（点の後は何桁でも）のうちの1つである。

最も単純なケースは、0.6の確率による任意の拡張（0か1の発生）である。その文法は、拡張がマッチする確率が60%で、拡張が存在しない確率が40%であることを示す。

以下は、より複雑な例である。もし文法が単語"x"が"0.8"の確率で2-4回繰り返されるということを示しているならば、その文法は以下の発生確率を示している：

少なくとも2回繰り返し：拡張とマッチする確率が100%になるので、少なくとも2つの"x"が必要である。"x"の確率は80%である。もう1つの"x"の確率は20%である。
正確に2回の繰り返し：確率20%
少なくとも3回の繰り返し：確率80%
正確に3回の繰り返し：確率16%
少なくとも4回の繰り返し：確率64%
正確に4回の繰り返し：確率64%（4回の繰り返しの最大）
4回以上の繰り返し：0%（繰り返し範囲が2-4であることから）。

（全体の合計が100%：20%+16%+64%であることに注目）

（m-）の範囲において最大が指定されない時、その確率は急激に低下する。

特殊なケース

任意のVOIDは、NULLに等しい。

NULLを何回繰り返しても、1つのNULLに等しい。

繰り返しの数が0（例えば<0>または<0-0>）だけというのがあるならば、拡張は入力によって決してマッチしないし、まるで規則定義の中に含まれないようにふるまう。

ABNF形式

任意の拡張は、四角括弧で区切られる：[拡張]。

次のものは、postfix演算子である："<m-n> <m->"。postfix演算子は、論理的に進行している拡張に付与される。Postfix演算子は高い優先順位を持つが、すぐ前の拡張（2.8節を参照）にtighlyな密接に結びつく。

次のシンボルは、ABNFで将来の使用のために確保されている："* +？"。そして、構文が現在繰り返し演算子を許可している文法のどの場所でも使われてはならない。

 
	// the token "very" is optional
	[very]
	very <0-1>

	// the rule reference $digit can occur zero, one or many times

	$digit <0->

	// the rule reference $digit can occur one or more times

	$digit <1->

	// the rule reference $digit can occur four, five or six times
	$digit <4-6>

	// the rule reference $digit can occur ten or more times
	$digit <10->

	// Examples of the following expansion
	//   "pizza"
	//   "big pizza with pepperoni"
	//   "very big pizza with cheese and pepperoni"
	[[very] big] pizza ([with | and] $topping) <0->

繰り返し確率は、その範囲形式でサポートされるだけである。確率は、スラッシュ・キャラクタによって区切られて、角括弧の範囲内で含まれる："<m-n/prob/>"と"<m-/prob/>"

 
	// the token "very" is optional and is 60% likely to occur
	// and 40% likely to be absent in input
	very <0-1 /0.6/>

	// the rule reference $digit must occur two to four times with 80% recurrence
	$digit <2-4 /.8/>

XML形式

"item"要素は、含まれた拡張が繰り返される回数を示す"repeat"属性を持つ。次のテーブルでは、属性の認められた値を定義している。

 
	<!-- the token "very" is optional -->

	<item repeat="0-1">very</item>

	<!-- the rule reference to digit can occur zero, one or many times -->

	<item repeat="0-"> <ruleref uri="#digit"/> </item>

	<!-- the rule reference to digit can occur one or more times -->

	<item repeat="1-"> <ruleref uri="#digit"/> </item>

	<!-- the rule reference to digit can occur four, five or six times -->
	<item repeat="4-6"> <ruleref uri="#digit"/> </item>

	<!-- the rule reference to digit can occur ten or more times -->
	<item repeat="10-"> <ruleref uri="#digit"/> </item>

	<!-- Examples of the following expansion -->
	<!--   "pizza" -->
	<!--   "big pizza with pepperoni" -->
	<!--   "very big pizza with cheese and pepperoni" -->

	<item repeat="0-1"> 
	   <item repeat="0-1"> very </item>
	   big 
	</item> 
	pizza
	<item repeat="0-">
	   <item repeat="0-1">
	      <one-of>
	         <item>with</item>
	         <item>and</item>
	      </one-of>
	   </item>
	   <ruleref uri="#topping"/>
	</item>

アイテム要素のrepeat-probは、繰り返し確率をもたらす。また繰り返し属性が指定されないならば、繰り返し確率はいくつかのアイテム要素でサポートされるが、無視される。

 
	// the token "very" is optional and is 60% likely to occur
	// and 40% likely to be absent in input
	<item repeat="0-1" repeat-prob="0.6">very</item>

	// the rule reference $digit must occur two to four times with 80% recurrence
	<item repeat="2-4" repeat-prob=".8"> <ruleref uri="#digit"/> </item>

2.6. タグ

タグは、いくつかの正当な規則拡張のインラインに含まれる任意のストリングである。タグは、文法によって定義される正当な単語パターンまたは文法があれば音声または他の入力を認識するプロセスに影響を及ぼさない。

どんな数のタグでも、規則拡張の範囲内のインラインに含まれる。

タグは、文法（より具体的には、規則定義と規則拡張にマッチする）にマッチする音声認識結果のポスト処理において、一般的に使われる情報を提供する。

W3C Voice Browser Working Groupは、現在"音声認識のための意味解釈"の仕様を開発している。口語的な入力を意味結果に変換するために使われる文法タグのための言語を定義する。この仕様の中の文法タグの例は、仕様の公表に従って更新される。

タグ・フォーマット宣言は、文法における全てのタグの内容タイプを示す。文法プロセッサが他のフォーマットをサポートするかもしれないが、デフォルトのタグフォーマットは今度のW3C"音声認識のための意味解釈"タグフォーマットであるとする。

特殊なケース

独立型拡張としてタグを使用することは、正当である。例えば、規則は1つのタグとトークン以外に拡大する。

 
	$rule = {content};

 
	<rule id="rule"><tag>content</tag></rule>

ABNF形式

タグは、一対の開閉curly括弧のどちらか--'{'と'}'--またはタグの範囲内であまり出現しそうにないと思われる次の3-キャラクタ・シーケンス--'{!{'と'}!}'によって区切られる。タグの内容は、文法プロセッサで解析されない。

タグの範囲内に含まれる閉括弧は、バックスラッシュで逃れられる。バックスラッシュはまた、バックスラッシュで逃れられなければならない。

タグ優先順位は、規則参照とトークンに関するものと同じものである。下記の最初の例で、6つのスペース分離された拡張（3つのトークン、タグ、トークン、タグ）のシーケンスがある。2つ目の例で、選択肢はトークンとタグを含んでいるシーケンスまたは規則参照とタグを含んでいるシーケンスである。

 
	$rule1 = this is a {tag1} test {tag2};

	$rule2 = open {action='open';} | $close {action='shut';};

	$rule3 = {!{ a simple tag containing { and } without escaping }!};

XML形式

"tag"要素は、"item"と"rule"要素の直接的な子でありえる。タグの内容は、CDATAである。

 
	<rule id="rule1">this is a <tag>tag1</tag> test <tag>tag2</tag> </rule>

	<rule id="rule2">
	   <one-of>
	      <item> open <tag>action='open'</tag> </item>
	      <item> <ruleref uri="close"/> <tag>action='shut'</tag> </item>
	   </one-of>
	</rule>

2.7. 言語と場所

アプリケーションが多言語使用のユーザコミュニティを目標とする状況下では、異なる言語の単語を含む文法が必要とされる。例えば、次のようなプロンプトに対して："Andre Prevostと話したいか？"（フランス語の名前と英文の組合せ）、応答は"yes"か"oui"である。この場合、英語とフランス語の応答のためにそれぞれ2つの文法を定義することが可能である。しかしながら、両方の可能性を含む文法を定義することは、有効でより単純である。

母国語や話している言語によって異なる発音またはアクセントで話されている適当な名前（人、通り、会社、その他）を扱う多言語使用のアプリケーションのための関連したチャレンジがある。ユーザが特定のトークンを発音するために用いる言語を予測することは不可能である。例えば、名前"Robert Jones"は"Jones"のために英語の発音だが、"Robert"のためにフランス語の発音を使っているフランス語を話しているユーザによって発音される。だが一方、一言語使用の英語の話者は両方の単語に対して英語の発音を使う。

ABNFとXMLの両文法形式は、言語と場所を示すための3つの方法をサポートする。言語/場所は、RFC 1766識別子または識別子のスペース分離されたシーケンスによって示される。

[注：RFC 1766はRFC 3066によって不当とされるが、その変化は小さくて音声認識への限られた関連である。文法仕様はXML仕様に従っているので、RFC 1766参照に続く。]

トークンアタッチメント：1つ以上の言語は、per-token基礎の上で任意に指定される。もし複数の言語が指定されるならば、認識器は並行であるトークンのためのそれぞれの言語の発音、音声上の目録そして音響モデルを適用しなければならない。文法プロセッサは、1つ、多数または言語/場所の全てがプロセッサでサポートされていない言語/場所宣言を取り扱う際にいくつかの適応性を持つ。詳細は5.4節と5.6節を参照。
規則拡張アタッチメント：1つの言語は、いくつかの規則拡張のために指定される。（複数の言語には、per-token基礎の上を除いて付加されない。）
文書宣言：4.1.2節では、文法のデフォルト言語を宣言するための方法を定義する。トークンアタッチメントまたは規則拡張アタッチメントが文書場所宣言を無効にしない限り、文法の中の全てのトークンは同じ場所にある。

範囲指定している言語：言語宣言は、文書と規則定義に対してローカルに範囲指定される。XML用語では、言語属性は文書木（duccument tree）の下で継承される。言語変化がもう一つの文法への参照を含んでいる場合、参照された規則とその含んでいる文法は参照拡張の言語を定義する。規則参照の間際の影響の中にある言語には、参照された規則に対する影響がまったくない。

言語識別子を文法構造に付与することは、その構造の範囲内に含まれるトークンのための音声認識器への指示である。それは発音規則、音声上の目録、そして指定された言語識別子に対応している音響モデルを使っていなければならない。いくつかの言語が与えられたトークンのために指定されるならば、それぞれの言語の発音、音声上の目録、そして音響モデルは全く平行に扱われなければならない。

ABNF形式

ABNF形式に関して、言語識別子は区切り文字として感嘆符を使っているトークンまたは規則拡張に付与される。言語識別子は、規則拡張の範囲内の全てのトークンに適用される。複数の言語によるトークン・アタッチメントのために、言語識別子は分離されるコンマ（cf.スペース分離されたはやりのXML書式）である。

 
	#ABNF 1.0 ISO-8859-1;

	// default grammar language is US English
	language en-US;

	// single language attachment to tokens
	$yes = oui!fr-CA | yes!en-US

	// single language attachment to a rule expansion
	$request = May I speak to (Michel Tremblay | Andre Roy)!fr-CA

	// multiple language attachment to a token
	$people1 =  Robert!en-US,fr-CA;

	// and the equivalent single-language attachment expansion
	$people2 =  Robert!en-US | Robert!fr-CA

XML形式

XML形式に関して、"lang-list"属性がいくつかの規則拡張要素に付与される："one-of"、"token"または"item"。"lang-list"属性は"ruleref"要素に付加されるが、範囲指定している規則のためにまったく影響がない。それに加えて、"token"要素は場所のスペース分離されたリストによる個々のトークンのために複数の言語を指定している"lang-list"属性と一緒に使用される。

 
	<?xml version="1.0"?>

	<!-- the default grammar language is US English -->
	<grammar xmlns="http://www.w3.org/2001/06/grammar" xml:lang="en-US" version="1.0">

	<!-- single language attachment to tokens -->
	<rule id="yes">
	<one-of>
	 <item lang-list="fr-CA">oui</item>
	  <item lang-list="en-US">yes</item>

	</one-of> 
	</rule> 

	<!-- single language attachment to a rule expansion -->
	<rule id="request">
	may I speak to
	<one-of lang-list="fr-CA">

	  <item>Michel Tremblay</item>
	  <item>Andre Roy</item>
	</one-of>
	</rule>

	<!-- multiple language attachment to a token -->
	<rule id="people1">
	<token lang-list="en-US fr-CA"> Robert </token>

	</rule>

	<!-- the equivalent single-language attachment expansion -->
	<rule id="people2">
	<one-of>
	 <item lang-list="en-US">Robert</item>
	  <item lang-list="fr-CA">Robert</item>

	<one-of>
	</rule>

	</grammar>

2.8. 優先順位

この節では、規則拡張構文の優先順位を定義する。XML文書では明確に体系を示しているので曖昧さがなく、したがって優先順位定義は必要ない。ABNF形式のための優先順位定義は、括弧の必要性を最小にするものである。

ABNF形式

以下は、規則拡張の優先順位を順序である。括弧は、必要に応じて明確に規則体系を制御するのに用いられる。

ドル記号'$'、提示されたトークン、提示されなかったトークンもしくはタグによって示された規則名
分類のための括弧"()"、そして任意の分類のための括弧"[]"。
繰り返しカウント（例えば、'<0-1>）は、最もきつい直前の規則拡張に適用される。（分類'()'もしくは'[]'の使用法をシーケンスまたは選択肢に適用する）
規則拡張のシーケンス。
選択肢規則拡張の集合を区切る'|'。

XML形式

XML体系は明確であるので、何もなし。

3. 規則定義

規則定義は、正当な規則拡張を規則名と結びつける。規則定義はまた、規則定義の範囲を定義することもしている：それが定義される文法に中でローカルであるかどうかに関係なく、あるいはそれが他の文法の範囲内で参照されているかどうかに関係なく。結局、規則定義はさらに文書コメントと他の語用論を含む。

規則名は、文法の範囲内で一意でなければならない。同じ規則名が、それぞれの規則定義をユニークに同定する方法を定義している規則名決定仕様で複数の文法において使用される。

3.1：基本的な規則定義
3.2：規則定義の範囲指定
3.3：例フレーズ

3.1. 基本的な規則定義

規則定義の中心的な目的は、正当な規則拡張を規則名と結びつけることである。

正当な規則名とは、Extensible Markup Language（XML）1.0仕様によって定義されたような正当なIDでなければならない。そのID制約は、文法のXML形式とABNF形式の両方に適用される。

正当な規則名は、終結キャラクタ'.'、コロンキャラクタ':'またはハイフンキャラクタ'-'（全てがXML IDの正当なキャラクタであるけれども）を含むことができない。この制約は、文法仕様と厳密に結び付けられる"音声認識のための意味解釈"仕様のための一貫した構文を許可する。この制約は、文法のXML形式とABNF形式の両方に適用される。

規則名は、XML文法とABNF文法において大文字と小文字の区別ができる。正確なストリング比較が、分析された規則名参照に使われる。

正当な規則名は、特殊な規則ではない：すなわち、"NULL"、"VOID"または"GARBAGE"。

ABNF形式

規則定義は、正当な規則名に従う任意の範囲指定している宣言（次の節で説明）、等号、正当な規則拡張、そして終了のセミコロンからなる。規則定義は、次の正当な書式のうちの1つを持つ：

 
	$ruleName = ruleExpansion;
	public $ruleName = ruleExpansion;
	private $ruleName = ruleExpansion;

例えば：

 
	$city = Boston | "New York" | Madrid;
	$command = $action $object;

特殊なケース

空の規則定義は不当である。

空の括弧と$NULL（等価の形式）に拡張する規則を定義することは、正当である。1つのタグに拡張する規則を定義することは、正当である。

 
	// Legal
	$rule = ();
	$rule = $NULL;
	$rule = {tag};

	// ILLEGAL
	$rule = ;

XML形式

規則定義は、"rule"要素で表される。要素の"id"属性は規則の名前を示し、文法の範囲内で一意でなければならない（これは、XMLによって強制される）。"rule"要素の内容は、2節で定義されたいくつかの正当な規則拡張である。"scope"属性は、次の節で説明される。

 
	<rule id="city">
	   <one-of>
	      <item>Boston</item>
	      <item>"San Francisco"</item>
	      <item>Madrid</item> 
	   </one-of>
	</rule>
	<rule id="command">
	   <ruleref uri="#action"/>
	   <ruleref uri="#object"/>
	</rule>

特殊なケース

空の規則要素または空白CDATAだけを含む規則要素を定義することは、正当でない。

空のアイテムまたはNULLの1つの規則参照に拡張する規則を定義することは、正当である。

1つのタグ要素に拡張する規則を定義することは、正当である。

 
	<!-- Legal -->
	<rule id="rule"><item/></rule>
	<rule id="rule"><ruleref special="NULL"/></rule>
	<rule id="rule"><tag>content</tag></rule>

	<!-- ILLEGAL -->
	<rule id="rule"/>
	<rule id="rule"></rule>
	<rule id="rule">   </rule>

3.2. 規則定義の範囲指定

規則定義は文法でローカルとして定義されるか、もしくは外部に対して参照可能で動作可能である。ローカルな範囲での規則は、プライベートである。外部に参照可能である規則は、パブリックでなければならない。範囲が規則定義で明確に述べられない限り、規則はプライベートにデフォルト設定する。

パブリックに範囲指定された規則は他の文法の規則定義に参照される（プライベートに範囲指定された規則は参照されることができない）。4節は、規則参照の便利な表記をサポートするエイリアスメカニズムとnamespace分析を説明する。エイリアスは、単に速記参照構文であって、規則の範囲指定している動作を変えない。

1つの例外は、ルートとして宣言された規則はたとえそれがプライベート規則であるとしても外部に参照されるということである。詳細は4.1.4節を参照。

パブリックな範囲による規則は、認識のために動作する。すなわち、それらは口語的な入力に対するトップレベルの構文を定義する。例えば、VoiceXML文法動作は1つのパブリック規則または複数のパブリック規則を明確に参照する。

範囲指定する意味は、文法立案者が動作規則を別の場所での使用を目的として輸出された規則と区別することができるようにするということである。ここで定義される範囲指定のメカニズムは、Java(TM)プログラミング言語のそれに最も近い。

ABNF形式

規則定義は、"public"または"private"によって注釈がつけられる。範囲が与えられないならば、デフォルトは"private"である。

 
	$town = Townsville | Beantown;
	private $city = Boston | "New York" | Madrid;
	public $command = $action $object;

XML形式

"rule"要素の"scope"属性は、規則定義の範囲を定義する。定義された値は、"public"、そして"private"である。省略されるならば、デフォルトの範囲は"private"である。

 
	<rule id="town">
	   <one-of>
	      <item>Townsville</item>
	      <item>Beantown</item> 
	   </one-of>
	</rule>
	<rule id="city" scope="private">
	   <one-of>
	      <item>Boston</item>
	      <item>"San Francisco"</item>
	      <item>Madrid</item> 
	   </one-of>
	</rule>
	<rule id="command" scope="public">
	   <ruleref uri="#action"/>
	   <ruleref uri="#object"/>
	</rule>

3.3. 例フレーズ

定義とともに規則定義にマッチするフレーズの例を含めることは、望ましい。0、1または多くの例フレーズが、いくつかの規則定義のために用意されている。例が明確に指定されるので、自動ツールが回帰テストのため、そして文法文書の生成のために使われる。

ABNF形式

文書コメントは、関連した規則定義に先行するキャラクタシーケンス/**から始まるC/C++/Javaコメントである。0以上の"@example"タグは、文書コメントの終端にはさまれる。例のtokenizationは、2節で定義されるtokenizationとシーケンス規則に従う。

 
	/**
	 * A simple directive to execute an action.
	 *
	 * @example open the window
	 * @example close the door
	 */
	public $command = $action $object;

XML形式

"rule"要素の範囲内の最初の内容として、何個かの"example"要素が与えられる。例のtokenizationは、2節で定義されるtokenizationとシーケンス規則に従う。

 
	<rule id="command" scope="public">
	    <!-- A simple directive to execute an action. -->
	    <example> open the window </example>
	    <example> close the door </example>
	    <ruleref uri="#action"/> <ruleref uri="#object"/>
	</rule>

4. 文法ドキュメント

文法ドキュメントは一組の合同規則を指定する。文法内で定義されたすべての規則は、文法の名前空間の範囲内となる。文法内で定義された規則は、それぞれ独立した名前を付けなくてはならない。XML形式では、文法名はXMLIDであり、完全XMLドキュメント内で独立したIDでなければならない。

何の規則も定義されていない文法も合法である。この場合、文法がユーザ入力とのパターンマッチングを定義しないので、文法をインプット処理のために使用することができない。

4.1:文法のヘッダ
- 4.1.1:文字コード
- 4.1.2:文法のロケール
- 4.1.3:文法のモード
- 4.1.4:ルートルールの宣言
- 4.1.5:タグ形式の宣言
4.2:エイリアス
4.3:発話辞書
4.4:メタ宣言
4.5:コメント
4.6:文法フェッチ
4.7:ABNFのキーワード

4.1. 文法のヘッダ

文法のヘッダでは、文法のバージョン、文字コード、言語/現場、モード、(すべての文法ドキュメントのために必要になるとは限りらないが)ルートを宣言する。ABNF形式では、この情報は宣言が後続する自己識別ヘッダとして示される。XML形式では、このヘッダ情報はXMLヘッダおよびルート文法要素によってコード化される。

この仕様に従う文法は、バージョンを「1.0」であると宣言しなければならない。注:このバージョンは、文法に実装される仕様のバージョンを示しており、文法内容のバージョニングのためではない(内容バージョニングのためにメタ宣言を使用できる)。

このセクションでは、ABNF文法とXML文法におけるヘッダの全面的な構造を示す。サブセクション(4.1.1?4.1.5)では、言語/現場、モード、ルート、それぞれのヘッダ特性を定義する。次のセクション(4.2?4.5)では文法における他の宣言(エイリアス、辞書、メタ、コメント)について定義する。

ABNF形式

ABNFヘッダは、3つの省略可能な宣言(言語宣言、モード宣言、ルート宣言、タグ形式宣言)が厳密な順に後続する自己識別ヘッダから成る。

ABNFドキュメントの最初の文字は"#"シンボル(x23)であり、その直後に正確な文字列"ABNF"(x41 x42 x4d x46)が続くかなければならない。

その後、空白(x20)を一つ挟んで、バージョン番号(この仕様を使うならば、"1.0"(x31 x2e x30))が入れられる。

次に、文字コード(省略可能)が入る。文字コードについての詳細はサブセクション4.1.1で定義するが、これを入れる場合はバージョン番号との間に空白(x20)を一つ挟まなければならない。

自己識別ヘッダは直後に新しい行が続く";"(x3b)で終わる。新しい行の取り扱いはXML規格に従う。従って";"は、バージョン番号か(提示されたら)文字コードに続く最初の文字となる。

ABNFヘッダの残りの宣言について、空白はそれほど重要ではない。

さらに、それぞれの宣言の間にコメントを点在させることができる。但し、宣言内にはできない。

以下に、すべての宣言を含んだABNFヘッダの例を2つ示す。

	#ABNF 1.0 ISO-8859-1;
	
	language en;
	mode voice;
	root $myRule;

	#ABNF 1.0;
	
	// A French Canadian grammar
	language fr-CA;
	
	// It's a speech grammar
	mode voice;
	
	// Here's the root rule
	root $QuebecCities;

XML形式

XML文法のドキュメントのヘッダは、XML宣言、DOCTYPE宣言(省略可能)、ルート文法要素(省略可能)を含む。

XML宣言のバージョン番号は、XMLのどのバージョンが使用されているかを示す。文法要素のバージョン番号は、文法仕様のどのバージョンが使用されているか示す(この仕様の場合は"1.0")。

文法要素はxmlns属性を使用して、文法の名前空間を指定しなければならない。XMLにおける名前空間はhttp://www.w3.org/2001/06/grammarで定義してある。

現在の場合、DOCTYPEは標準のDOCTYPE及び識別子を参照すべきである。

	<!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR 1.0//EN"
                  "http://www.w3.org/TR/speech-grammar/grammar.dtd">

文字コードは、XMLの仕様で定義したように、XML宣言中に定義される(詳細:4.1.1)。

言語/現場はXML形式で文法要素のlang属性として定義される(詳細:4.1.2)。

文法のモードは文法要素中に定義される(詳細:4.1.3)。

ルートルールも文法要素中に定義される(詳細:4.1.4)。

タグ形式も文法要素中に定義される(詳細:4.1.5)。

以下に、すべての宣言を含んだXML文法のヘッダの例を2つ示す。内1つはDOCTYPE宣言を含む。

	<?xml version="1.0" encoding="ISO-8859-1"?>
	<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
	         xml:lang="en" mode="voice" root="myRule">

	<?xml version="1.0" encoding="ISO-8859-1"?>
	
	<!DOCTYPE grammar PUBLIC "-//W3C//DTD GRAMMAR 1.0//EN"
	                  "http://www.w3.org/TR/WD-speech-grammar/grammar.dtd">
	
	<grammar version="1.0" xmlns="http://www.w3.org/2001/06/grammar"
	         xml:lang="fr-CA" mode="voice" root="QuebecCities">

4.1.1. 文字コード

文字コードは、ドキュメントの中で使用される記号セットを示す。例えば、アメリカのアプリケーションの場合、一般的にASACIIかISO-8859-1である。日本の文法においては、JISやUnicodeのような文字コードが使用可能である。

異なる構文的な表現を除いて、ABNF文法形式は、XMLにおいて定義された文字コードの振る舞いに従う。XML文法プロセッサはISO/IEC 10646のUTF-16、UTF-8の両方を受け付けなければならない。なぜなら、XML文法プロセッサはXML準拠なプロセッサであるからである。このようにしてそれらの文字コードをサポートするように要求した。一貫性のため、ABNF文法プロセッサもまた、ISO/IEC 10646のUTF-8、UTF-16の両方を受け付けなければならない。

XML文法およびABNF文法の両方について、文字コードは省略可能であるが指示することをお勧めする。XMLは、文字コード表示のないXMLドキュメントを受け取るときのXMLプロセッサの動作を定義している。一貫性のため、ABNF文法プロセッサも同じ動作に(異なる構文のための調節を含むが)従わねばならない。

ABNF形式

文字コードは4.1で定義された、文法の自己識別ヘッダの一部分となる。

以下に文字コード表示のあるABNF文法の自己識別ヘッダと、ないヘッダを示す。

	#ABNF 1.0 ISO-8859-1;

	#ABNF 1.0 JIS;

	#ABNF 1.0;

XML形式

XMLでは、文字コードはドキュメントの最初の行のXML宣言の一部分となるように定義してある。

以下に文字コード表示のあるXMLのヘッダと、ないヘッダを示す。

	<?xml version="1.0" encoding="ISO-8859-1"?>

	<?xml version="1.0" encoding="JIS"?>

	<?xml version="1.0"?>

4.1.2. 文法のロケール

文法のロケールは、ドキュメントによって含まれている主要な言語を示す。また、自由に国あるいは他の変化も示す。XMLの仕様に従い、ロケールは言語/国コードRFC 1766によって識別される。言語コードはRFC 1766によって要求される。国コードあるいは他のサブタグ識別子はRFC 1766によって省略可能である。

注:RFC 1766はRFC 3066により軽視されているが、その変更は小さいし、音声認識に関係のある部分は限られてる。文法仕様はXML仕様に従うので、RFC 1766を参照しつづけることになる。

ロケール宣言はすべての音声認識文法において要求される。このとき、すべての文法におけるモードは"voice"である(注:XMLにおけるmode属性やABNFにおいて明白なモード宣言がない場合、モードのデフォルト値はvoiceとなる)。

XML文法を、別のXMLドキュメント内に組み込む(例えばVoiceXML 2.0でサポートされたように)場合、そのときxml:lang属性は文法要素上で省略可能にできる。また、xml:lang属性はXML文法を囲むドキュメントから継承されなければならない。

ロケール宣言はDTMF文法において省略可能であり、無視される。このときすべての文法のモードは"dtmf"となる。

サポートされていない言語変形に遭遇する場合、5章での適合定義で文法プロセッサの動作を定義する。

ABNF形式

この場合、言語宣言は、自己認識ヘッダに続くABNF文法ファイルの最初のコメント無し宣言となる。

キーワード"language"の前、キーワード"language"とRFC1766の間、RFC1766と";"の間、";"の後に空白を置いてもよい。

キーワード"language"と";"の間にコメントを入れてはいけない。

	language en-US;

	language fr;

XML形式

XML規格に従い、言語とその変化形は"grammar"要素上の"xml:lang"属性によって示される。文法のバージョンは"version"属性によって表わされる(この仕様の場合は"1.0")。

	<grammar xmlns="http://www.w3.org/2001/06/grammar" xml:lang="en-US" version="1.0">

	<grammar xmlns="http://www.w3.org/2001/06/grammar" xml:lang="fr" version="1.0">

4.1.3. 文法のモード

文法のモードは、ユーザエージェントが検知するべき入力のタイプを示す。音声認識文法におけるデフォルトのモードは"voice"である。付録Eで定義されている選択可能な入力モードとして"dtmf"がある。

"mode"属性は、文法により含まれるトークンを解釈する方法を示す。音声トークンは、トークンのように聞こえる音声オーディオとして検知されると思われる。(対応しているとしたら)DTMFトークンは、ITU Recommendation Q.24により検知される。

多くの場合、音声認識のためによりもDTMF音の検知のために異なるユーザエージェントが使用される。仕様の今後の変更で定義される他のモードについても同じことが言えるかもしれない。

この仕様では一つの文法が複数のモードを混合するようなメカニズムについては定義しない。つまり、"voice"や"dtmf"を混合した文法の提示の方法などは定義しないということである。さらに、一つの文法を参照したルールが、異なるモードを備えた他の任意の文法を参照することは違法である。同様に、異なるモードの文法にエイリアス参照を定義することも違法である。

しかしながら、ユーザエージェントは"dtmf"文法と"voice"文法の両方を含む一つ以上の文法の同時有効化に対応できる。これは、例えばVoiceXMLブラウザなどに必要である(並列の有効化は、文法の構造内のモード混合ではなく文法のルートレベルでの離接を意味する)。

ABNF形式

現在の場合、省略可能なモード宣言は言語宣言に続くべきである。そうでなければ、自己識別ヘッダに続くABNF文法ファイルの最初の非コメント宣言であるべきである。モード宣言が省略される場合、モードはデフォルトの"voice"となる。そのときモード宣言が"dtmf"である場合、文法によって含まれるトークンは付録Eに定義されるようなDTMFイベントを形成する。

	mode voice;

	mode dtmf;

XML形式

モード宣言は、ルートのgrammar要素の省略可能なmode属性として提示される。認めている値は"voice"(デフォルト)および"dtmf"である。

	<grammar mode="voice"
	         version="1.0" xml:lang="en-US" xmlns="http://www.w3.org/2001/06/grammar">

	<grammar mode="dtmf" 
	         version="1.0" xml:lang="en-US" xmlns="http://www.w3.org/2001/06/grammar">

4.1.4. ルートルールの宣言

この文法仕様では、ルール参照を、外部文法の特定の公のルール定義あるいは別の文法内に定義された明示的に宣言された"root"ルールのいずれかに付けることができる。ルートルールの参照における構文はSecsion2.2で定義してある。文法が仕様に従ったルートルールを宣言しない場合に、そのルートにより文法を参照するとエラーとなる。

XMLとABNFの両形式において、単一のルールが文法のルートルールであることを、文法ヘッダーで自由に宣言することができる。宣言されたルートルールはその文法の範囲内で定義されるルールでなければならない。

宣言されルートルールはpublicあるいはprivateであるものとして、範囲に入ることができる。publicなルールの場合、ルートとしての外部参照とその名前による外部参照に動作の差はない。privateなルールとしてルートルールを宣言した場合、それはルートとしてでしか外部参照されない。

指定されるルールは、"ruleref"要素がルール名識別子のない文法を参照する場合(URI参照、エイリアス参照両方に適用)に参照するルールとなる。

文法はルートルールを宣言するように要求されないが、それは任意の文法の根規則を宣言するよい習慣である。

ABNF形式

省略可能なルートルール宣言は、(ある場合)言語宣言やモード宣言に続かなければならない。そうでなければ、ABNF文法ファイルにおいて自己識別ヘッダに続く最初のコメント無しの宣言となる。ルート宣言は、同じ文法内のどこか他のところで定義された1ルールと見分けがつかなければならない。

	root $rulename;

XML形式

ルートルール名は、"grammar"要素上の省略可能な"root"属性として提示される。ルート宣言は、同じ文法内のどこか他のところで定義された1ルールと見分けがつかなければならない。

	<grammar root="rulename" ...>

4.1.5. タグ形式の宣言

タグ形式の宣言は、文法内に含まれているタグのcontent typeを示す。指定された場合、文法内のすべてのタグの内容は宣言された形式でなければならない。

タグ形式の識別子は、タグ形式の仕様により指定される。タグ形式の識別子を、スラッシュによって分離されたタグ形式名およびバージョン番号の両方から構成することをお勧めする。

W3C Voice Browser Working Groupは、現在、音声認識仕様のための意味的解釈を立案している。それが利用可能な場合、W3C semantic tagがタグ形式のデフォルトとなるだろう。また、それに従うすべての文法プロセッサにはその形式に対応することが要求される。更に、文法プロセッサはデフォルトとは別のタグ形式に対応するかもしれない。

W3C semantic tagのための識別子は、"semantics/1.0"のようなものが予想される。この識別子は、文法仕様のこのバージョンを実行する、タグ形式を明示的に宣言しない文法のためのデフォルトのタグ形式となる。

W3C semantic tag以外の形式のタグを含む文法は、その形式を指定する明示的なタグ形式の宣言を行わなければならない。

ABNF形式

"tag-format"宣言は、(ある場合)言語宣言、モード宣言、ルート宣言の後に続かなければならない。"tag-format"宣言は、すべてのエイリアス宣言、辞書宣言、メタ宣言、ルール定義に先行する。

	tag-format semantics/1.0;

XML形式

タグ形式は、"grammar"要素上の省略可能な"tag-format"属性として提示される。

	<grammar tag-format="semantics/1.0" ...>

4.2. エイリアス

エイリアスは、外部定義文法やそれらの文法の公ルールへの参照において便利な機能である。エイリアス宣言は、そのURIによって識別される外部文法のローカルな名前を割り当てる。エイリアスを行った文法のルールを参照する場合、ルール参照(2.2.2で定義)は、そのルールの完全なURIの代わりにエイリアスで指定した別名を使用することができる。外部文法を何度も参照するような場合、エイリアスを使用することにより文法全体を読みやすくすることができる。

エイリアス名は文法内でそれぞれ重複してはならない。他のURI参照のように、エイリアス宣言は参照された文法をコピーすることはなく、単に短い名前による参照を許すだけである。

エイリアス名はルール名と同じ名前空間にはない。従って、同じ名前を備えた、エイリアスとルール定義の両方を宣言することは有効である。

エイリアスで宣言されたURIは、絶対的又は相対的な任意のURIかもしれないが、fragment separatorを含めなければならない。

外部文法URI参照(2.2.2)のように、エイリアス宣言ではメディアタイプ提示の省略が許される。もし省略されれば、文法のタイプは他の手段(例えばhttpヘッダー)によって決定される。

この文法仕様のABNF形式とXML形式におけるメディアタイプは、まだ決定されていない。

ABNF形式

0、1、またはそれ以上の"alias"宣言は省略可能な"language"宣言に続くが、文法中のルール定義をpreceedする。以下に、外部文法のためのエイリアスステートメントを定義する。

	alias $(http://www.mygrammars.com/cities-states.gram) $$places;
	
	
	
	// References the "city" rule defined in the "places" grammar
	... $$places#city ...

省略可能なメディアタイプ宣言は、2.2.2節に外部文法ルール参照のために記述されたものと同じ形式となる。

	alias $(http://www.mygrammars.com/cities-states.gram)~(application/grammar) $$places;

XML形式

0、1、またはそれ以上の"alias"要素は"grammar"要素内に主要な要素として含まれ得る。"alias"要素は"rule"要素をpreceedしなければならない。"alias"要素は空要素である。"uri"属性や"name"属性がそれぞれ必要となるが、"type"属性は省略可能である。

	<alias uri="http://www.mygrammars.com/cities-states.xml"
	        name="places"/>
	
	
	 <!-- Reference the "city" rule in the "places" grammar -->
	 ... <ruleref alias="places#city"/> ...

参照される文法のためのメディアタイプ宣言は"type"属性により宣言される(2.2.2節で記述されている外部文法ルール参照のためのメディア・タイプ宣言と同じ構文となる)。

	<alias uri="http://www.mygrammars.com/cities-states.xml"
	        name="places" type="application/grammar+xml"/>

4.3. 発話辞書

文法は1またはそれ以上の外部発話辞書ドキュメントを参照することができる。辞書ドキュメント内に含まれる発話情報は、囲んだ文法内のトークンにのみ使われる。このとき、トークンのための発話が外部辞書に位置する場合、この発話はプラットフォームのデフォルトの辞書にある任意の発話に加えて使用される。

発話辞書ドキュメントのフォーマットは、標準のW3C Prounciation Lexicon Markup Languageの仕様まではプラットフォーム依存である。結果として、トークンテキストと発話辞書の内容を照合するプロセスもまたプラットフォーム依存となる。

ABNF形式

0、1、またはそれ以上の"lexicon"宣言は省略可能な"alias"宣言に続いて提示する。現在の場合、"lexicon"宣言は、文法内のすべてのメタ宣言とすべてのルール宣言をpreceedしなければならない。

	#ABNF V1.0 ISO-8859-1;
		language en-US;
		alias $(http://www.example.com/grammar.gram) $$mygrammar;
		lexicon $(http://www.example.com/lexicon.file);
		lexicon $(http://www.example.com/strange-city-name.file);
		...

XML形式

0、1またはそれ以上の"lexicon"要素は、"grammar"要素の子要素として生じる。"lexicon"には"uri"属性が1つ存在し、それで発話辞書ドキュメントの存在場所を指定する。

	<grammar xmlns="http://www.w3c.org/2001/06/grammar" xml:lang="en" version="1.0">
		<alias uri="http://www.example.com/place.xml" name="someplaces"/>
		<lexicon uri="http://www.example.com/lexicon.file"/>
		<lexicon uri="http://www.example.com/strange-city-name.file"/>
		...

4.4. メタ宣言

文法ドキュメントは著者に様々な方法でメタデータ(ドキュメントコンテンツではなく、ドキュメントに関する情報)を指定させる。メタ情報は、エイリアス宣言や辞書宣言の前にの文法ヘッダ内に現れる。

例えば、"meta"はXML文法ドキュメントの著者を指定するのに使われる。以下に"meta"要素が、プロパティ(ここでは"Author")やそれに対する値の割り当て(ここでは"Stephanie Williams")を指定する例を示す。

	meta "Author" is "Stephanie Williams";

	<meta name="Author" content="Stephanie Williams"/>

この文書では必要なメタデータプロパティを特に指定しないが、以下に(HTMLやVoiceXMLに基づいて)推奨できるものを示す。

名前	記述内容
author	著者について記述する情報
copyright	著作権の通知
description	サーチエンジンのためのドキュメントの記述
keywords	ドキュメントについて記述するキーワード
maintainer	ドキュメント保持者の電子メールアドレス
robots	検索エンジンwebロボットへの誘導

属性名	記述内容
name	メタデータプロパティの名前
content	メタデータプロパティの値
http-equiv	HTTPレスポンスヘッダの名前。nameかhttp-equivのいずれかが指定されなければならない。両方を指定する必要はない。

この仕様では、ABNFやXMLの両形式に対して等価なメタコンテンツ宣言の表現を定義する。

ABNF形式

ドキュメントのヘッダにおいて"meta"宣言か"http-equiv"宣言のいずれかを使用してメタ情報を提示する。現在の場合、"meta"宣言及び"http-equiv"宣言は、自己認識ヘッダや(提示されるなら)言語宣言、モード宣言、ルート宣言、エイリアス宣言、辞書宣言に続かなければならない。さらに、文法内のすべてのルールをpreceedしなければならない。"meta"宣言と"http-equiv"宣言は混同されてもよい。

	#ABNF 1.0;
	
	meta "author" is "Stephanie Williams";
	meta "maintainer" is "mhunt@acme.com";
	...

http-equivの宣言は、個別の宣言形式を使用するが、ドキュメントのヘッダのメタ宣言と同じセクションに現れる。

	#ABNF 1.0;
	
	http-equiv "Expires" is "0";
	http-equiv "Data" is "Thu, 12 Dec 2000 23:27:21 GMT";
	...

XML形式

"meta"要素において"name"属性と"content"属性を使用して、ドキュメントのプロパティを宣言する。1またはそれ以上の"meta"要素は、以下の例に示すようにドキュメントの"grammar"要素に続く。

	<?xml version="1.0"?>
	
	<grammar version="1.0" xml:lang="en-US"
			xmlns="http://www.w3c.org/2001/06/grammar">
		<meta name="author" content="Steohanie Williams"/>
		<meta name="maintainer" content="mhunt@acme.com"/>
		...
	</grammar>

以下の例では、一つ目の"meta"要素はドキュメントのキャッシュを防ぐ有効期限をセットし、二つ目の"meta"要素は日付データをセットする。

	<?xml version="1.0"?>
	
	<grammar version="1.0" xml:lang="en-US"
			xmlns="http://www.w3c.org/2001/06/grammar">
		<meta http-equiv="Expires" content="0"/>
		<meta http-equiv="Date" content="Thu, 12 Dec 2000 23:27:21 GMT"/>
		
		...
	</grammar>

4.5. コメント

コメントは文法ドキュメントの最も多くの場所に置かれるかもしれない。XML形式ではXMLコメントを使用し、ABNF形式ではドキュメンテーション・コメントやC/C++/Javaスタイルのコメントを使用する。

ABNF形式

C/C++/Javaスタイルのコメントが許される。ドキュメンテーション・コメントは文法宣言、言語宣言、エイリアス宣言の前やそれぞれのルール宣言の前で許される。

3.3節では、ルール宣言の前のドキュメンテーション・コメント内の表現例におけるフォーマットを定義している。

	// C++/Java-style single-line comment
	/* C/C++/Java-style comment */
	/** Java-style documentation comment */

XML形式

XMLコメントは以下のような構文である。

	<!-- comment -->

4.6. 文法フェッチ

ABNF、XMLの両文法ドキュメントにおけるフェッチ動作およびキャッシュ動作は、先ず文法プロセッサが作動する環境によって定義される。例えば、VoiceXML 1.0およびVoiceXML 2.0では、有効化された文法に当てはまるフェッチ動作およびキャッシュ動作はVoiceXMLブラウザによって定義される。同様に、ABNF文法またはXML文法に対応する認識器用のどんなAPIも、フェッチ動作およびキャッシュ動作を当てはめることができる。

文法プロセッサには、ドキュメントの新しさを決定する目的で、文法を「与える」と解釈できる動作への対応が推奨される。

文法の活性化は認識器が文法と一致するユーザ入力の検知を始めるポイントにある、従ってシステム出力のAV演出のアクションと類似している。出力演出でのように、文法の新しさは文法活性化の瞬間においてチェックされるべきである。

4.7. ABNFのキーワード

ABNF言語のキーワードは保存されていない。ABNF中でのキーワードとその意味は以下に示す通りである。

コンテキスト	キーワード
言語宣言	"language"
モード宣言	"mode"
ルート宣言	"root"
エイリアス宣言	"alias"
発話辞書	"lexicon"
メタ、またはHTTP-equiv宣言	"meta"、"http-equiv"、"is"
ルール定義	"public"、"private"

キーワードが保存されていないので、それらはエイリアス名、ルール名、トークンとして使用してもよい。下記に示した例は、(極端で役立たないとはいえ)仕様に合った文法である。

	#ABNF 1.0 ISO-8859-1;
	
	language en-AU;
	root $public;
	mode voice;
	
	alias $(http://public.example.com/public.gram) $$public;
	
	public $public = public $public | $$public;

5. 適合

この節が標準となる。

文法適合基準の異なるセットは以下に記述するところにおいて存在する。

5.1:適合したXML文法フラグメント
5.2:適合したStand-Alone XML文法ドキュメント
5.3:他の名前空間を用いたXML文法の使用
5.4:適合したXML文法プロセッサ
5.5:適合したStand-Alone ABNF文法ドキュメント
5.6:適合したABNF文法プロセッサ
5.7:適合したABNF/XML文法プロセッサ
5.8:適合したユーザエージェント

5.1. 適合したXML文法フラグメント

XML文法ドキュメント・フラグメントがDTDおよびスキーマを含むこの文書(Speech Recognition Grammar Format Specification)に記述された仕様に執着するような場合や以下に示すような場合、XML文法ドキュメント・フラグメントは適合したXMLドキュメント・フラグメントである。

XML文法ドキュメント・フラグメントが(XMLに関して)well-formedである場合
ドキュメントが以下に示す事柄の後に有効なXMLドキュメントである場合
- 文法に関係のないすべての名前空間要素および属性や、文法に関係のない名前空間要素を参照するすべてのxmlns要素がドキュメントから削除されている。
- 適切なXML宣言(つまり、<?xml ...?>)がドキュメントの一番上に含まれている。
- 文法DTDを指す適切なドキュメント・タイプ宣言(つまり、<!DOCTYPE grammar ...>)が、XML宣言の後直ちに含まれている。
以下に示すW3C勧告に適合する場合
- XML1.0仕様(Extensible Markup Language (XML) 1.0)
- (文法以外のいずれかの名前空間がドキュメントの中で使用される場合)XMLにおける名前空間

XML文法言語あるいはこれらの適合基準は、文法ドキュメントの様相に対する指定のサイズ制限を提供しない。要素の数、文字データの量、属性値中の文字の数については上限なしである。

5.2. 適合したStand-Alone XML文法ドキュメント

以下のような場合、そのファイルは適合したStand-Alone XML文法ドキュメントである。

XMLドキュメントである場合
そのルート要素が"grammar"要素である場合
適合XML文法フラグメントの基準に適合する場合

5.3. 他の名前空間を用いたXML文法の使用

文法の名前空間は、XMLにおける名前空間勧告により他のXML名前空間と共に使用されてもよい。W3Cによる今後の計画は、多数の名前空間を含むドキュメントのための適合を指定する方法に取り組むことだろう。

5.4. 適合したXML文法プロセッサ

XML文法プロセッサはXML文法フラグメントを解析、処理するプログラムである。ここで示す例は、XML文法形式を受理する音声認識器およびDTMF検知器を含んでいる。

適合したXML文法プロセッサでは、XMLパーサはXML1.0やXML Namespaces内で定義されたすべてのXML構文を解析、処理できなければならない。

適合したXML文法プロセッサは、このドキュメントによって定義された個々の可能な文法特徴の意味論を正確に理解し適用しなければならない。

適合したXML文法プロセッサは、言語と地域の取り扱いのための次の必要条件を満たさなければならない。

適合した文法プロセッサには、すべての言語宣言をうまく解析するよう求められる
適合した文法プロセッサは、対応できていない言語あるいは地域に遭遇するかどうかを、その集合環境に通知すべきである。
与えられた言語/地域に対応できる適合した文法プロセッサは、この同じ与えられた言語/地域において、ルート、任意の一つの公ルール、各ルート/ルールおよびすべての直接あるいは間接的に参照されたサブルールが、この同じ与えられた言語/現場のためにある場合の1またはそれ以上の文法の任意の公ルール/ルートの集合を有効化できなければならない。
それぞれのルール/ルート、及び直接/間接に参照されたすべてのサブルールが1つの言語/地域(各言語/地域がすべて同じとは限らない)を含むような、あるいは少なくとも1つのルール/ルートか少なくとも直接/間接に参照されたサブルールに1以上の言語/地域を含むような1以上の文法の任意の公ルール/ルート集合や、ルートや、任意の1つの公ルールを、適合した文法プロセッサは有効化できる。文法プロセッサがその集合の中で各言語/地域に対応できるが、それらを同時に扱うことができない場合、ホスト環境にそのことを通知するべきである。その集合が、文法プロセッサに対応していない1以上の言語/地域を含む場合も、ホスト環境にそのことを通知するべきである。
適合した文法プロセッサは、ドキュメント化され、プラットフォーム依存の動作によるおおよその置換により地域をインプリメントするかもしれない。例:US英語の音声認識器をイギリス英語入力の処理に使用する。

適合した文法プロセッサが文法以外の名前空間内の要素/属性に遭遇した場合、以下のような動作ができる。

そのような要素/属性を無視する。
そのような要素/属性を処理する
そのような要素/属性を含むようなドキュメントを拒否する。

適合したXML文法プロセッサは再帰的な文法(すなわちルール参照が直接/間接の自己参照を含んでいる文法)に対応する必要はない。

しかしながら、そこにはXML文法プロセッサの実行特性に関しての適合要求はない。例えば、ステートメントには、正確さ、速度あるいは音声認識器/DTMF検知器の他の特性に関しての要求はない。ステートメントは、文法のサイズあるいはXML文法プロセッサが対応しなければいけない文法語彙のサイズに関して発表されない。

5.5. 適合したStand-Alone ABNF文法ドキュメント

ABNF文法ドキュメントが形式上のABNF仕様を含むこのドキュメント(Speech Recognition Grammar Format Specification)に記述された仕様に従う場合、ABNF文法ドキュメントは適合したABNFドキュメントだといえる。

5.6. 適合したABNF文法プロセッサ

ABNF文法プロセッサはABNF文法ドキュメントを解析し処理することができるプログラムである。この例は、ABNF文法形式を受理する音声認識器およびDTMF検知器を含んでいる。

適合したABNF文法プロセッサは、このドキュメントによって定義された個々の可能な文法特徴の意味論を正確に理解し適用しなければならない。

適合したABNF文法プロセッサは、適合したXML文法プロセッサのために5.4節で概説されるように必要条件を扱う同じ言語/地域に従わなければならない。

適合したABNF文法プロセッサは、それが処理することができない不法な文法ドキュメントあるいは他の文法コンテンツに遭遇した場合、そのことをホスト環境に通知するべきである。

適合したABNF文法プロセッサは再帰的な文法(すなわちルール参照が直接/間接の自己参照を含んでいる文法)に対応する必要はない。

しかしながら、そこにABNF文法プロセッサの実行特性に関しての適合要求はない。例えば、ステートメントには、正確さ、速度あるいは音声認識器/DTMF検知器の他の特性に関しての要求はない。ステートメントは、文法のサイズあるいはABNF文法プロセッサが対応しなければいけない文法語彙のサイズに関して発表されない。

5.7. 適合したABNF/XML文法プロセッサ

適合したABNF/XML文法プロセッサーは、5.4節と5.6節の中で定義された適合基準をすべて満たさなければならない。

さらに、ABNF/XML文法プロセッサーはXML文法からABNF文法への参照やABNF文法からXML文法への参照を、解決し適用できなければならない。

5.8. 適合したユーザエージェント

適合したユーザエージェントとは、文法のモードのユーザ入力(つまり、音声入力なら"voice"モード、DTMF入力なら"dtmf"モード)を受理することができ、さらに以下に示す動作が可能な適合したXML文法プロセッサ、あるいは適合したABNF文法プロセッサ、あるいは適合したABNF/XML文法プロセッサである。

ユーザ入力のシーケンスがいつ正確に文法と一致するか決定する。
入力がどのように文法と一致するか示す出力表現を作成する。

問題:今後の計画として、音声認識仕様のための意味的な解釈をさらに対応することが適合したユーザエージェントに求められるだろう。意味的解釈の仕様は、まだW3C Voice Browser Working Groupにより開発中である。

現在の音声認識技術は統計的に基づく。出力が決定論的でなく、入力の正確な表現と保証ができないので、正確さに関しての適合要求はない。しかしながら、適合テストは適合を決定するため、音声入力の正確な認識のいくつかの例を要求するかもしれない。

6. 謝辞

このドキュメントは、W3C Voice Browser Working Groupのメンバー(以下にアルファベットの順に示す)の参加で記述された。

Mike Brown, Lucent Bell Labs
Dan Burnett, Nuance Communications
Debbie Dahl, Unisys
Andrew Hunt, SpeechWorks International
Stefan Krause, Philips
Bruce Lucas, IBM
Jens Marschner, Philips
Scott McGlashan, PipeBeach
Yves Normandin, Locus Dialogue
Dave Raggett, W3C/OpenWave
David Ramsthaler, Cisco
Luc Van Tichelen, Lernout & Hauspie
Kuansan Wang, Microsoft

付録A. ABNF形式とXML形式の文法の例

以下に示すのは、「open a file.」「please move the window.」といったコマンドに対応した簡単な文法である。この文法は、別々定義されたさらに上級の文法(ここには示さないが)を参照する。

ABNF形式

	#ABNF 1.0 ISO-8859-1;
	
	language en;mode voice;
	root $basicCmd;
	alias $(http://www.sayplease.com/politeness.gram) $$polite;
	
	
	meta "author" is "Stephanie Williams";
	
	/**
	 * Basic command.
	 * @example please move the window
	 * @example open a file
	 */
	
	public $basicCmd = 
	          $$polite#startPolite $command $$polite#endPolite;
	
	$command = $action $object;
	$action = /10/ open {'OPEN'} | /2/ close {'CLOSE'} 
	                 | /1/ delete {'DELETE'} | /1/ move {'MOVE'};
	$object = [the | a] (window | file | menu);

XML形式

	<?xml version="1.0"?>
	
	<grammar xmlns="http://www.w3.org/2001/06/grammar" 
	        xml:lang="en" version="1.0" mode="voice" root="basicCmd">
	
	<alias name="polite"
	        uri="http://www.sayplease.com/politeness.xml"/>
	
	
	<meta name="author" content="Stephanie Williams"/>
	
	<rule id="basicCmd" scope="public">
	  <example> please move the window </example>
	  <example> open a file </example>
	
	 <ruleref alias="polite#startPolite"/>
	
	  <ruleref uri="#command"/>
	 <ruleref alias="polite#endPolite"/>
	
	</rule>
	
	<rule id="command">
	  <ruleref uri="#action"/> <ruleref uri="#object"/>
	</rule>
	
	<rule id="action">
	   <one-of>
	    <item weight="10"> open   <tag>'OPEN'</tag> </item>
	      <item weight="2">  close  <tag>'CLOSE'</tag> </item>
	      <item weight="1">  delete <tag>'DELETE'</tag> </item>
	      <item weight="1">  move   <tag>'MOVE'</tag> </item>
	
	    </one-of>
	</rule>
	
	<rule id="object">
	 <item repeat="0-1">
	
	    <one-of>
	      <item> the </item>
	      <item> a </item>
	    </one-of>
	 </item>
	
	  <one-of>
	      <item> window </item>
	      <item> file </item>
	      <item> menu </item>
	  </one-of>
	</rule>
	
	</grammar>

次の2つの文法は、XML形式およびABNF形式の両文法においての参照を示している。

ABNF:http://www.example.com/places.gram

	#ABNF 1.0 ISO-8859-1;
	
	language en;mode voice;
	root $city_state;
	// No aliases  in this referenced grammar.
	
	public $city = Boston | Philadelphia | Fargo;
	
	public $state = Florida | North Dakota | New York;
	
	// References to local rules
	// Artificial example allows "Boston, Florida!"
	
	public $city_state = $city $state;

ABNF:http://www.example.com/booking.gram

	#ABNF 1.0 ISO-8859-1;
	
	language en;
	mode voice;
	
	alias $(http://www.example.com/places.gram) $$someplaces;
	
	
	// Reference by URI syntax
	$flight = I want to fly to
	   $(http://www.example.com/places.gram#city);
	
	// Reference using alias name
	$exercise = I want to walk to $$someplaces#state;
	
	// Reference to root rule using an alias reference
	$wet = I want to swim to $$someplaces;

XML:http://www.example.com/places.xml

	<?xml version="1.0"?>
	
	<grammar xmlns="http://www.w3.org/2001/06/grammar" 
	        xml:lang="en" version="1.0" root="city_state" mode="voice">
	
	   <rule id="city" scope="public">
	     <one-of>
	       <item>Boston</item>
	       <item>Philadelphia</item>
	       <item>Fargo</item>
	     </one-of>
	   </rule>
	
	   <rule id="state" scope="public">
	     <one-of>
	       <item>Florida</item>
	       <item>North Dakota</item>
	       <item>New York</item>
	     </one-of>
	   </rule>
	
	   <!-- Reference by URI to a local rule -->
	   <!-- Artificial example allows "Boston, Florida"! -->
	   <rule id="city_state" scope="public">
	     <ruleref uri="#city"/> <ruleref uri="#state"/>
	   </rule>
	</grammar>

XML:http://www.example.com/booking.xml

	<?xml version="1.0"?>
	
	<grammar xmlns="http://www.w3.org/2001/06/grammar" 
	        xml:lang="en" version="1.0" mode="voice">

 	<alias name="someplaces"
 	        uri="http://www.example.com/places.xml"/>
	
	
	   <!-- Using URI syntax -->
	   <rule id="flight">
	     I want to fly to 
	     <ruleref uri="http://www.example.com/places.xml#city"/>
	   </rule>
	
	   <!-- Using alias syntax -->
	   <rule id="exercise">
	     I want to walk to 
	     <ruleref alias="someplaces#state"/>
	   </rule>
	
	   <!-- Reference to root rule of a grammar by alias -->
	   <rule id="wet">
	     I want to swim to 
	     <ruleref alias="someplaces"/>
	   </rule>
	</grammar>

付録B. XML形式のためのDTD

この付録が標準となる。

	
	<?xml version="1.0" encoding="ISO-8859-1"?>
	
	<!-- Speech Recognition Grammar Format DTD v0.93 20010816 -->
	
	<!ENTITY % rule-expansion "#PCDATA | token | ruleref
	                              | item | one-of | tag " >
	
	<!ELEMENT ruleref EMPTY>
	<!ATTLIST ruleref
	     uri CDATA #IMPLIED
	     alias CDATA #IMPLIED
	     type CDATA #IMPLIED
	     special (NULL | VOID | GARBAGE) #IMPLIED
	     lang-list NMTOKENS #IMPLIED>
	
	<!ELEMENT token (#PCDATA)>
	<!ATTLIST token
	     lang-list NMTOKENS #IMPLIED>
	
	<!ELEMENT tag (#PCDATA)>
	
	<!ELEMENT one-of (item)*>
	<!ATTLIST one-of
	     lang-list NMTOKENS #IMPLIED>
	
	<!ELEMENT item (%rule-expansion;)*>
	<!ATTLIST item
	    repeat NMTOKEN #IMPLIED
	    repeat-prob NMTOKEN #IMPLIED
	    weight NMTOKEN #IMPLIED>
	
	<!ELEMENT rule (%rule-expansion; | example )*>
	<!ATTLIST rule 
	    id ID #REQUIRED
	    scope (private | public) "private">
	
	<!ELEMENT example (#PCDATA)>
	
	<!ELEMENT alias EMPTY>
	<!ATTLIST alias
	    uri CDATA #REQUIRED
	    type CDATA #IMPLIED
	    name NMTOKEN #REQUIRED>
	
	<!ELEMENT lexicon EMPTY>
	<!ATTLIST lexicon
	    uri CDATA #REQUIRED>
	
	<!ELEMENT meta EMPTY>
	<!ATTLIST meta
	    name        NMTOKEN     #IMPLIED
	    content     CDATA       #REQUIRED 
	    http-equiv  NMTOKEN     #IMPLIED>
	
	<!ELEMENT grammar (alias | lexicon | meta | rule)*>
	<!ATTLIST grammar 
	    tag-format CDATA #IMPLIED
	    version NMTOKEN #REQUIRED
	    xml:lang NMTOKEN #IMPLIED
	    root IDREF #IMPLIED
	    mode (voice | dtmf) "voice">

付録C. XML文法形式のためのスキーマ

この付録が標準となる。

	<?xml version="1.0" encoding="ISO-8859-1"?>
	<schema targetNamespace="http://www.w3.org/2001/06/grammar"
	           xmlns:xml="http://www.w3.org/XML/1998/namespace"
	           xmlns:t="http://www.w3.org/2001/06/grammar"
	           xmlns="http://www.w3.org/2001/XMLSchema"
	           elementFormDefault="qualified">
	  <import namespace="http://www.w3.org/XML/1998/namespace" 
	           schemaLocation="http://www.w3.org/2001/xml.xsd"/>
	  <simpleType name="lang-list">
	    <restriction base="NMTOKENS"/>
	  </simpleType>
	  <simpleType name="tag">
	    <restriction base="string"/>
	  </simpleType>
	  <simpleType name="example">
	    <restriction base="string"/>
	  </simpleType>
	  <group name="rule-expansion">
	    <choice>
	      <element name="token" type="t:token"/>
	      <element name="ruleref" type="t:ruleref"/>
	      <element name="item" type="t:item"/>
	      <element name="one-of" type="t:one-of"/>
	      <element name="tag" type="t:tag"/>
	    </choice>
	  </group>
	  <complexType name="ruleref">
	    <attribute name="type" type="string"/>
	    <attribute name="uri" type="anyURI"/>
	    <attribute name="alias" type="string"/>
	    <attribute name="special">
	      <simpleType>
	        <restriction base="NMTOKEN">
	          <enumeration value="NULL"/>
	          <enumeration value="VOID"/>
	          <enumeration value="GARBAGE"/>
	        </restriction>
	      </simpleType>
	    </attribute>
	    <attribute name="lang-list" type="t:lang-list"/>
	  </complexType>
	  <complexType name="token" mixed="true">
	    <annotation>
	      <documentation>
	does not expression the constraint that empty content is illegal
	</documentation>
	    </annotation>
	    <attribute name="lang-list" type="t:lang-list"/>
	  </complexType>
	  <complexType name="one-of">
	    <sequence minOccurs="0" maxOccurs="unbounded">
	      <element name="item" type="t:item"/>
	    </sequence>
	    <attribute name="lang-list" type="t:lang-list"/>
	  </complexType>
	  <complexType name="item" mixed="true">
	    <choice minOccurs="0" maxOccurs="unbounded">
	      <group ref="t:rule-expansion"/>
	    </choice>
	    <attribute name="repeat-prob">
	      <simpleType>
	        <restriction base="float">
	          <minInclusive value="0.0"/>
	          <maxInclusive value="1.0"/>
	          <pattern value="[0-9]+(.[0-9]+)?"/>
	          <pattern value="([0-9]+)?.[0-9]+"/>
	        </restriction>
	      </simpleType>
	    </attribute>
	    <attribute name="repeat">
	      <simpleType>
	        <annotation>
	          <documentation>
	does not expression the constraint in n-m that m must be greater than n
	</documentation>
	        </annotation>
	        <restriction base="string">
	          <pattern value="[0-9]+"/>
	          <pattern value="[0-9]+-([0-9]+)?"/>
	          <pattern value="([0-9]+)?-[0-9]+"/>
	        </restriction>
	      </simpleType>
	    </attribute>
	    <attribute name="weight">
	      <simpleType>
	        <restriction base="float">
	          <minInclusive value="0.0"/>
	          <pattern value="[0-9]+"/>
	          <pattern value="([0-9]+)?.[0-9]+"/>
	        </restriction>
	      </simpleType>
	    </attribute>
	  </complexType>
	  <complexType name="rule" mixed="true">
	    <choice minOccurs="0" maxOccurs="unbounded">
	      <group ref="t:rule-expansion"/>
	      <element name="example" type="t:example"/>
	    </choice>
	    <attribute name="id" use="required">
	      <simpleType>
	        <annotation>
	          <documentation>
	does not expression the constraint that NULL VOID GARBAGE are illegal as rule name
	</documentation>
	        </annotation>
	        <restriction base="ID">
	          <pattern value="[^.:-]+"/>
	        </restriction>
	      </simpleType>
	    </attribute>
	    <attribute name="scope" default="private">
	      <simpleType>
	        <restriction base="NMTOKEN">
	          <enumeration value="private"/>
	          <enumeration value="public"/>
	        </restriction>
	      </simpleType>
	    </attribute>
	  </complexType>
	  <complexType name="alias">
	    <attribute name="type" type="string"/>
	    <attribute name="uri" type="anyURI" use="required"/>
	    <attribute name="name" type="NMTOKEN" use="required"/>
	  </complexType>
	  <complexType name="lexicon">
	    <attribute name="uri" type="anyURI" use="required"/>
	  </complexType>
	  <complexType name="meta">
	    <attribute name="name" type="NMTOKEN"/>
	    <attribute name="content" type="string" use="required"/>
	    <attribute name="http-equiv" type="NMTOKEN"/>
	  </complexType>
	  <complexType name="grammar">
	    <choice minOccurs="0" maxOccurs="unbounded">
	      <element name="alias" type="t:alias"/>
	      <element name="lexicon" type="t:lexicon"/>
	      <element name="meta" type="t:meta"/>
	      <element name="rule" type="t:rule"/>
	    </choice>
	    <attribute name="tag-format" type="string"/>
	    <attribute name="version" type="NMTOKEN" use="required"/>
	    <attribute ref="xml:lang"/>
	    <attribute name="root">
	      <simpleType>
	        <annotation>
	          <documentation>
	does not expression the constraint that NULL VOID GARBAGE are illegal as rule name
	</documentation>
	        </annotation>
	        <restriction base="IDREF">
	          <pattern value="[^.:-]+"/>
	        </restriction>
	      </simpleType>
	    </attribute>
	    <attribute name="mode" default="voice">
	      <simpleType>
	        <restriction base="NMTOKEN">
	          <enumeration value="voice"/>
	          <enumeration value="dtmf"/>
	        </restriction>
	      </simpleType>
	    </attribute>
	  </complexType>
	  <element name="grammar" type="t:grammar"/>
	</schema>

付録D. Augmented BNFのための形式上の構文

この付録が標準となる

ここに使用される記法は、XML1.0仕様によって定義されたEBNF記法に従う。

ABNFにおける語彙の文法

	SelfIdentHeader  ::= '#ABNF' #x20 VersionNumber (#x20 CharEncoding)? ';'
	
	VersionNumber    ::= Nmtoken                           
	     
	CharEncoding     ::= Nmtoken
	
	LanguageCode     ::= Nmtoken
	
	RuleName         ::= '$' ConstrainedName
	
	TagFormat        ::= (NameChar | '/')+
	
	GrammarURI       ::= '$' '(' URIC+ ')'                 /* in the DTD: CDATA */
	
	MimeType         ::= '(' MimeTypeChar+ ')'
	
	LexiconURI       ::= '(' URIC+ ')'                     /* in the DTD: CDATA */
	
	AliasName        ::= '$$' ConstrainedName              
	
	QuotedCharacters ::= '"' CharData '"'
	     
	
	Weight           ::= '/' [0-9]+ '/' | '/' [0-9]* '.' [0-9]+ '/'
	
	RepeatOperator   ::= '+' | '*' | '<' [0-9]+ ('-' [0-9]*)? (' ' Probability)? '>'
	
	Probability      ::= '1' | '0' | '1' '.' '0'+ | '0'? '.' [0-9]+
	
	URIRuleRef       ::= '$' '(' URIC+ '#' Name ')'
	
	URIRootRef       ::= '$' '(' URIC+ ')'
	
	AliasRuleRef     ::= AliasName '#' ConstrainedName
	
	AliasRootRef     ::= AliasName
	
	Token            ::= Nmtoken | QuotedCharacters
	
	----------------------------------------------------------------------------------
	
	URIC is defined by the uric production of RFC2396.
	It is the set of all characters, which are allowed within a URI.
	
	Name is defined by the XML Name production.
	
	ConstrainedName is a Name, which does not contain a dot, colon or hyphen.
	
	Nmtoken is defined by the XML Nmtoken production.
	
	NameChar is defined by the XML NameChar production. It defines the set of
	characters, which are allowed in an NMTOKEN.
	
	CharData is defined by the XML CharData production.

ABNFにおける構文的な文法

	grammar         ::= header  declarations ruleDefinition*
	
	header          ::= SelfIdentHeader localeDecl? modeDecl? rootDecl? tagFormatDecl?
	
	localeDecl      ::= 'language' LanguageCode ';'
	
	modeDecl        ::= 'mode' 'voice' ';' | 'mode' 'dtmf' ';'
	
	rootDecl        ::= 'root' RuleName ';'
	
	tagFormatDecl   ::= 'tag-format' TagFormat ';'
	
	
	declarations    ::= aliasDecl* lexiconDecl* metaDecl*
	
	aliasDecl       ::= 'alias' GrammarURI ('~' MimeType)?  AliasName ';'
	
	lexiconDecl     ::= 'lexicon' LexiconURI ';'
	
	metaDecl        ::= 'meta' QuotedCharacters 'is' QuotedCharacters ';'
	                    | 'http-equiv' QuotedCharacters 'is' QuotedCharacters ';'
	
	ruleDefinition  ::=  scope? RuleName '=' ruleExpansion ';'   [VC: unique rule name]
	
	scope           ::= 'private' | 'public'
	
	ruleExpansion   ::= ruleAlternative ( '|' ruleAlternative )*
	
	ruleAlternative ::= Weight? sequenceElement+
	
	sequenceElement ::= subexpansion | subexpansion RepeatOperator
	
	subexpansion    ::= Token
	                    | ruleRef
	                    | tag
	                    | '(' ')'
	                    | '(' ruleExpansion ')'
	                    | '[' ruleExpansion ']'
	                    | Token '!' LanguageCode+
	                    | '(' ruleExpansion ')' '!' LanguageCode
	                    | '[' ruleExpansion ']' '!' LanguageCode
	
	ruleRef         ::= localRuleRef | externalRuleRef | specialRuleRef
	
	localRuleRef    ::= RuleName
	
	externalRuleRef ::= URIRuleRef | URIRootRef | AliasRuleRef | AliasRootRef
	
	specialRuleRef  ::= '$NULL' | '$VOID' | '$GARBAGE'
	
	tag             ::= '{' tagContent '}' | '{!{' tagContent '}!}'
	
	----------------------------------------------------------------------------------
	
	tagContent will be defined by the Semantic Interpretation 
	for Speech Recognition specification.

付録E. DTMF文法

この付録が標準となる

ここでは、DTMFトークンにおける文法構成の標準的な表現を定義する。DTMF文法は、DTMF検知機によって適切なDTMFイベント及び不適切なDTMFイベントを決定するために使用される。モード"drmf"に対応しているすべての文法はこの付録の内容を満たさなければならない。しかしすべての文法がDTMF入力に対応する必要はない。

DTMF(Dual Tone Multiple Frequency)は、電話シグナルにおけるITU標準である。ITU勧告Q23では、DTMFの生成を定義している。ITU勧告Q24では、DTMFの受理を定義している。

文法のモードがそのとき"dtmf"として宣言される場合、文法によって含まれていたトークンは、DTMFトーンとして(むしろ、音声認識トークンのデフォルトとして)扱われます。

DTMFトーンは16種類ある。そのうち12個は、一般の電話機で良くみられるような"0"?"9"の数字と"*"(スター)、"#"(ポンド)などである。そして典型的に電話上で存在しない4つのDTMFトーンは"A"、"B"、"C"、"D"である。

それぞれのDTMFシンボルはDTMF文法の中で合法的なDTMFトークンである。スペースで分離されたDTMFシンボルは、DTMFエントリの一時的なシーケンスを表わている。

ABNF形式では"*"シンボルは保存されるので、ABNF DTMF文法を定義する場合"*"を区切るためにクオートを常に使用しなければならない。"#"の場合もクオートを使用することが推奨される。代案として、"star"トークンおよび"pound"トークンは受理可能な同意語である。

現在の場合、ABNF文法内の言語宣言や、XML文法内のxml:lang属性や、lang-list属性は無視される。

その他のすべての点で、DTMF文法は構文上意味的な結果処理を含む音声認識文法と同じである。

下記はポンド("#")・ターミネータが後続する4桁PINを受理する単純なDTMF文法でである。さらに、それは"*9を許す(例:ヘルプメッセージを受け取るために"*9"を許す)。

ABNF形式

	#ABNF 1.0 ISO-8859-1;
	
	mode dtmf;
	
	$digit = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9;
	public $pin = $digit <4> "#" | "*" 9;

XML形式

	<?xml version="1.0"?>
	
	<grammar mode="dtmf" version="1.0" xmlns="http://www.w3.org/2001/06/grammar">
	
	<rule id="digit">
	 <one-of>
	   <item> 0 </item>
	   <item> 1 </item>
	   <item> 2 </item>
	   <item> 3 </item>
	   <item> 4 </item>
	   <item> 5 </item>
	   <item> 6 </item>
	   <item> 7 </item>
	   <item> 8 </item>
	   <item> 9 </item>
	 </one-of>
	</rule>
	
	<rule id="pin" scope="public">
	 <one-of>
	   <item>
	     <item repeat="4"><ruleref uri="#digit"/></item>
	     #
	   </item>
	   <item>
	     * 9
	   </item>
	 </one-of>
	</rule>
	
	</grammar>

付録F. XML文法をABNFに転換するためのXSLTスタイルシート

この付録が標準となる

下に提供される変形は、Augmented BNF形式へのXML形式文法の転換の図解である。ただし、以下に示す制限がかけられる。

コメントは変形されない。
空のトークン要素(それらはABNFにおいて不法である)の処理は無い。

	<?xml version="1.0"?> 
	
	<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	
	<xsl:strip-space elements= "alias rule example item one-of token"/>
	
	<xsl:output method="text"/>
	
	<xsl:template name="addweight">
	  <xsl:if test="string(@weight)!=''">
	    /<xsl:value-of select="@weight"/>/
	  </xsl:if>
	</xsl:template>
	
	
	<xsl:template name="addlanglist">
	  <xsl:if test="string(@lang-list)!=''">
	    !<xsl:value-of select="translate(normalize-space(@lang-list),' ',',')"/>
	  </xsl:if>
	</xsl:template>
	
	
	<xsl:template name="addrepeat">
	  <xsl:if test="string(@repeat)!=''">
	  <xsl:choose>
	    <xsl:when test="string(@repeat-prob)!=''">
	    &lt;<xsl:value-of select="@repeat"/> /<xsl:value-of select="@repeat-prob"/>/&gt;
	    </xsl:when>
	    <xsl:otherwise>
	    &lt;<xsl:value-of select="@repeat"/>&gt;
	    </xsl:otherwise>
	    </xsl:choose>
	  </xsl:if>
	</xsl:template>
	
	
	<xsl:template match="grammar">
	  #ABNF  <xsl:value-of select="@version"/> <xsl:value-of select="system-property('xsl:encoding')"/>;
	  <xsl:text> </xsl:text>
	  <xsl:if test="string(@xml:lang)!=''">
	  language <xsl:value-of select="@xml:lang"/>;
	  </xsl:if>
	  <xsl:if test="string(@mode)!=''">
	  mode <xsl:value-of select="@mode"/>;
	  </xsl:if>
	  <xsl:if test="string(@root)!=''">
	  root <xsl:value-of select="@root"/>;
	  </xsl:if>
	  <xsl:if test="string(@tag-format)!=''">
	  tag-format <xsl:value-of select="@tag-format"/>;
	  </xsl:if>
	  <xsl:apply-templates select="alias"/>
	  <xsl:apply-templates select="lexicon"/>
	 <xsl:apply-templates select="meta"/>
	  <xsl:apply-templates select="rule"/>
	</xsl:template>
	
	
	<xsl:template match="tag">
	    {<xsl:value-of select="."/>}
	</xsl:template>
	
	<xsl:template match="alias">
	  <xsl:choose>
	    <xsl:when test="string(@type)!=''">
	  alias $(<xsl:value-of select="@uri"/>)~(<xsl:value-of select="@type"/>) $$<xsl:value-of select="@name"/>;
	    </xsl:when>
	    <xsl:otherwise>
	  alias $(<xsl:value-of select="@uri"/>) $$<xsl:value-of select="@name"/>;
	    </xsl:otherwise>
	    </xsl:choose>
	</xsl:template>
	
	<xsl:template match="lexicon">
	lexicon $(<xsl:value-of select="@uri"/>);
	</xsl:template>
	
	<xsl:template match="meta">
	<xsl:if test="string(@content)!=''">
	<xsl:choose>
	<xsl:when test="string(@http-equiv)!=''">
	http-equiv "<xsl:value-of select="@http-equiv"/>" is "<xsl:value-of select="@content"/>";
	</xsl:when>
	<xsl:when test="string(@name)!=''">
	meta "<xsl:value-of select="@name"/>" is "<xsl:value-of select="@content"/>";
	</xsl:when>
	</xsl:choose>
	</xsl:if>
	</xsl:template>
	
	<xsl:template match="rule">
	  <xsl:value-of select="@scope"/>
	  $<xsl:value-of select="@id"/> = 
	  <xsl:apply-templates/>
	  ;
	</xsl:template>
	
	<xsl:template match="token">
	  (<xsl:value-of select="text()"/>)
	  <xsl:call-template name="addlanglist"/>
	</xsl:template>
	
	<xsl:template match="ruleref">
	  <xsl:choose>
	    <xsl:when test="string(@special)!=''">
	      $<xsl:value-of select="@special"/> 
	    </xsl:when>
	    <xsl:when test="string(@alias)!=''">
	      $$<xsl:value-of select="@alias"/>
	    </xsl:when>
	    <xsl:otherwise>
	      <xsl:choose>
	        <xsl:when test="starts-with(string(@uri),'#')">
	          $<xsl:value-of select="substring-after(@uri,'#')"/>
	        </xsl:when>
	        <xsl:otherwise>
	    <xsl:choose>
	        <xsl:when test="string(@type)!=''">
	          $(<xsl:value-of select="@uri"/>)~(<xsl:value-of select="@type"/>)
	        </xsl:when>
	    <xsl:otherwise>
	          $(<xsl:value-of select="@uri"/>)
	    </xsl:otherwise>
	    </xsl:choose>
	        </xsl:otherwise>
	      </xsl:choose>
	    </xsl:otherwise>
	  </xsl:choose>
	  <xsl:call-template name="addlanglist"/>
	</xsl:template>
	
	<xsl:template match="example"/>
	
	<xsl:template match="one-of">  <xsl:choose>
	    <xsl:when test="count(item)=0">
	    $VOID
	    </xsl:when>
	    <xsl:otherwise>
	        (<xsl:apply-templates/>)
	        <xsl:call-template name="addlanglist"/>
	    </xsl:otherwise>
	  </xsl:choose>
	</xsl:template>
	
	<xsl:template match="item">
	  <xsl:call-template name="addweight"/>
	  <xsl:apply-templates/> 
	  <xsl:call-template name="addrepeat"/>
	  <xsl:if test="not(position()=last())">|</xsl:if>
	</xsl:template>
	
	</xsl:stylesheet>

SRGF WD日本語版

目次

1. はじめに

1.1. 文法プロセッサとユーザー・エージェント

1.2. 範囲

1.3. 文法変換

1.4. 意味解釈

2. 規則拡張

2.1. トークン

2.2. 規則参照

2.2.1. ローカル参照

2.2.2. URIによる外部参照

2.2.3. エイリアスによる外部参照

2.2.4. 特別規則

2.2.5. N-gram文書を参照する

2.3. シーケンス

2.4. 選択肢

2.4.1. 重み

2.5. 繰り返し

2.6. タグ

2.7. 言語と場所

2.8. 優先順位

3. 規則定義

3.1. 基本的な規則定義

3.2. 規則定義の範囲指定

3.3. 例フレーズ

4. 文法ドキュメント

4.1. 文法のヘッダ

4.1.1. 文字コード

4.1.2. 文法のロケール

4.1.3. 文法のモード

4.1.4. ルートルールの宣言

4.1.5. タグ形式の宣言

4.2. エイリアス

4.3. 発話辞書

4.4. メタ宣言

4.5. コメント

4.6. 文法フェッチ

4.7. ABNFのキーワード

5. 適合

5.1. 適合したXML文法フラグメント

5.2. 適合したStand-Alone XML文法ドキュメント

5.3. 他の名前空間を用いたXML文法の使用

5.4. 適合したXML文法プロセッサ

5.5. 適合したStand-Alone ABNF文法ドキュメント

5.6. 適合したABNF文法プロセッサ

5.7. 適合したABNF/XML文法プロセッサ

5.8. 適合したユーザエージェント

6. 謝辞

付録A. ABNF形式とXML形式の文法の例

付録B. XML形式のためのDTD

付録C. XML文法形式のためのスキーマ

付録D. Augmented BNFのための形式上の構文

付録E. DTMF文法

付録F. XML文法をABNFに転換するためのXSLTスタイルシート

付録G. Media types and File Suffix

付録H. Logical Parse Structure

付録H.1. Terminology and Notation

付録H.2. Parsing Rule References

付録H.3. Recursion

付録I. Features under Consideration fpr Future Versions

索引