32 規則展開

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

32.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形式ではトークンは"token"要素ではっきりと区切られる。要素の内容は、一つのトークンに相当する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>
 

32.2 規則参照

規則名:すべての規則定義は、それが定義される文法の範囲内で一意でなければならないローカルな名前を持つ。正当な規則名は、2.3節での"Name"プロダクションと同様にXML仕様において定義される正当なXML IDでなければならない。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"/>

32.2.1 ローカル参照

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

ABNF形式

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

 
	$city
	$digit
 

XML形式

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

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

32.2.2 URIによる外部参照

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

URI参照は、文法のメディア・タイプの表示を伴うことができる。それが省略された場合は、文法タイプは他の手段(例えばhttpヘッダ)で決定される。

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

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

参照する文書のメディア・タイプが参照される文法のメディア・タイプと 一致していないとき、他の手段(例えば参照される文法の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のために予約済みである。詳細は*unresolved*を参照。

 
	// 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文法のために予約済みである。文法のためのメディア・タイプに関する詳細については*unresolved*を参照。

 
	<!-- 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"/>
 

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

32.2.4 特別規則

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

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

32.2.5 N-gram文書を参照する

Voice Browser Working Groupは、この仕様書と平行して確率的言語モデル(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文法文書への参照と同じ構文に従う。以下は、明示的な規則の参照、ルート規則の参照、および、エイリアス参照の例である。

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

XML形式

N-Gram文書へのURI参照エイリ アス参照は、他のABNF/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"/>
 

32.3 シーケンス

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

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

ABNF形式

正当な展開シーケンスは、空白によって区切られた展開要素の並びである。必要な場合、シーケンスは括弧で初めと終わりを区切ることができる。

 
	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>
 

特殊なケース

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

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

32.4 選択肢

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

32.4.1 重み

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

重みというのは名目上、音声認識検索の検索領域を拡大している原因である。以下は、音声認識技術というテーマおよび重みが適用される基本的な統計的枠組みに関する参考文献である。

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

選択肢の重みが指定されない場合、そのデフォルト値は"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>
 

32.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回繰り返されるということを示しているならば、その文法は以下の発生確率を示している:

(全体の合計が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"属性を持つ。次の例は属性の取り得る値を示している。

 
	<!-- トークン "very" は省略可 -->

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

	<!-- 規則digitへの参照は0または1回以上 -->

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

	<!-- 規則digitへの参照は1回以上 -->

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

	<!-- 規則digitへの参照は4,5,6回のいずれか -->
	<item repeat="4-6"> <ruleref uri="#digit"/> </item>

	<!-- 規則digitへの参照は10回以上 -->
	<item repeat="10-"> <ruleref uri="#digit"/> </item>

	<!-- 下記の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>
 

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

 
	// トークン "very" は省略可
  // 60% の確率で入力に出現する
	// 40% の確率で省略される
	<item repeat="0-1" repeat-prob="0.6">very</item>

	// 規則$digitへの参照は確率80%で再帰し、
  // 2回以上4回以下の繰り返しとなる
	<item repeat="2-4" repeat-prob=".8"> <ruleref uri="#digit"/> </item>
 

32.6 タグ

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

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

タグは、文法(具体的には、規則定義と規則展開)にマッチした音声認識結果の後処理において、一般的に使われる情報を提供する。

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

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

特殊なケース

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

 
	$rule = {content};
 
 
	<rule id="rule"><tag>content</tag></rule>  
 

ABNF形式

タグは、一対の中括弧のどちらか('{'と'}')、またはタグの範囲内であまり出現しそうにないと思われる次の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>
 

32.7 言語と場所

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

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

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

[注:RFC 1766はRFC 3066によって更新されているが、その変更は小さく、音声認識技術への影響は限られる。文法仕様はXML仕様に従っているので、RFC 1766参照に従う。]

範囲指定をしている言語:言語宣言は、文書と規則定義に対してローカルに範囲指定される。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>
 

32.8 優先順位

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

ABNF形式

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

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

XML形式

XML体系は明確であるので、該当事項はない。