35 文法ドキュメント

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

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

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

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

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

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

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

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

35.2 エイリアス

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

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

エイリアスで宣言されたURIは、絶対的又は相対的な任意のURIかもしれないが、fragment separatorを含めなければならない。外部文法URI参照(2.2.2)のように、エイリアス宣言ではメディアタイプ提示の省略が許される。もし省略されれば、文法のタイプは他の手段(例えばhttpヘッダー)によって決定される。この文法仕様のABNF形式とXML形式に おける*unresolved*は、まだ決定されていない。

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

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

35.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ロボットへの誘導

<meta>の二つ目のタイプは、HTTPのレスポンスヘッダを指定する。<meta>の、この使用法における属性は以下の通りである。

属性名 記述内容
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>

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

35.6 文法フェッチ

ABNF、XMLの両文法ドキュメントにおけるフェッチ動作およびキャッシュ動作は、先ず文法プロセッサが作動する環境によって定義される。例えば、VoiceXML 1.0およびVoiceXML 2.0では、有効化された文法に当てはまるフェッチ動作およびキャッシュ動作はVoiceXMLブラウザによって定義される。同様に、ABNF文法またはXML文法に対応する認識器用のどんなAPIも、フェッチ動作およびキャッシュ動作を当てはめることができる。文法プロセッサには、ドキュメントの新しさを決定する目的で、文法を「与える」と解釈できる動作への対応が推奨される。文法の活性化は認識器が文法と一致するユーザ入力の検知を始めるポイントにある、従ってシステム出力のAV演出のアクションと類似している。出力演出でのように、文法の新しさは文法活性化の瞬間においてチェックされるべきである。

35.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;