パーサー

パーサーは、RAW構成データを取得し、ネストされた属性構造に解析します。この構造はツリー階層で、ノードがコンテナで、リーフが名前と値のペアの属性、またはプロパティです。

構成拡張には、Oracleが提供するパーサーのホストが含まれています。各パーサーは、ベース・パーサーとパーサー・パラメータで構成されています。一部のパーサーには、解析後ルールも含まれます。ベース・パーサーは、基本的に、特定のフォーマットのデータを解析できるパーサーのカテゴリです。パーサー・パラメータは、データのフォーマットでの変動に対応するために、ベース・フォーマットを調整する方法を提供します。解析後ルールは、他に明確なアイデンティティがないツリー内のノードを調整するためのメカニズムです。これは、構成の比較や変更履歴の追跡によって誤検出の差異にフラグを付けることを回避する際に重要になります。またはこのメカニズムは、検索基準の指定やコンプライアンス・ルールで使用されるSQL問合せの作成に役に立ちます。

ベース・パーサーには次の4つがあります。

XML
フォーマット固有
列指向
プロパティ

一部のパーサーには、Oracleが提供するデフォルトのルールが含まれています。これらのルールは、ノードを調整する必要がある周知のインスタンスに対応します。特に、WebLogicおよびWebSphereパーサーには、このようなインスタンスに対応するデフォルト・ルールが含まれています。これらのルールはそのままにしておいても問題なく、これらのサブセットを実行することも、または独自のカスタム・ルールで置き換えることもできます。

この項の内容は次のとおりです。

パーサーの管理

構成拡張の作成、編集または表示の間、使用可能なパーサーのリスト、デフォルトのパラメータおよび該当する場合は解析後ルールを詳細に調べることができます。パーサー・パラメータは、コメント文字、デリミタ、開始および終了文字などの書式を決定します。これらのパラメータは編集できませんが、パーサーをXMLファイルとしてエクスポートし、ファイルを編集して、新しい名前でアプリケーションにインポートできます。また、一部のパーサーには、比較などを行うために、解析対象のツリー内のノードをそろえるデフォルト・ルールがあります。

構成拡張ライブラリで、「アクション」メニューから「パーサーの管理」を選択します。使用可能なパーサーのリストが表に表示されます。右側の列(ベース・パーサー)は一般的なパーサー・カテゴリ、たとえばプロパティを示しており、これはファイル・タイプを表し、名前/値のペアが含まれます。
パーサーを選択して、「詳細」をクリックします。このダイアログには、デフォルト・ルール(存在する場合)も表示されます。
- 「パラメータ」をクリックし、有効なパラメータのデフォルトを参照します。これにより、ファイル形式の規則に準拠するようにパーサーを編集する必要があるかどうかを判断できます。
- 「デフォルト・ルール」タブをクリックし、特定のパーサーとともに出荷される解析後ルールを参照します。これは、ルールの構成を把握するための便利な方法です。
指定されたパーサーのデリミタ文字を変更する場合は、次のようにします。
1. 表でパーサーを選択した状態で、「エクスポート」をクリックします。
2. 表示されるダイアログで「保存」をクリックして、ファイルシステムの場所に移動します。XMLファイルを適切な名前で保存します。
3. 編集する際には、Oracleが提供するパーサーのカスタマイズ・バージョンを作成しているので、XMLのパーサーIDとパーサー名を変更してください。
構成拡張の作成に使用するために保存した新しいパーサーをインポートする場合は、次のようにします。
1. パーサー表が開いた状態で、「インポート」をクリックします。
2. 表示されるダイアログで、エクスポートされたパーサー・ファイルを保存したファイルの場所を参照します。そのファイルを選択して、ダイアログの「インポート」をクリックします。
新しいパーサーが、構成拡張の作成に使用できる「パーサー」表に表示されます。

XMLパーサーについて

Cloud Controlには2つのXMLパーサーがあります。デフォルト(属性キー)XMLパーサーと汎用XMLパーサーです。

デフォルトXMLパーサーについて

解析は次のように行われます。

XML属性または子要素のないXML要素は解析対象属性になります。その他の要素はすべてコンテナになります。
XML属性は解析対象属性になります。
要素テキスト・コンテンツは解析対象属性になり、その名前はタグにXML属性が含まれているかどうかによって異なります。タグにXML属性が含まれている場合、解析対象属性の名前はSTORE_CONTENT_ASパラメータで指定された値を取得します。含まれていない場合、解析対象属性の名前はタグ名を取得します。

デフォルトXMLパーサーが受け入れるパラメータは次のとおりです。

パラメータ説明

パラメータ	説明
`MULTIKEY_DELIMITER`	`CONTAINER_NAME`パラメータでXML属性名のリストを区切るデリミタ。デフォルト: チルダ(~)
`STORE_CONTENT_AS`	要素にXML属性が含まれる場合に、要素テキスト・コンテンツから取得される、解析対象属性に付与される名前。デフォルト: `text_value`
`CONTAINER_NAME`	`MULTIKEY_DELIMITER`パラメータの値で区切られるXML属性名のリスト。このリストの属性名が元のファイルのタグに表示される場合、タグはXML属性の値で名付けられたコンテナになります。その他のすべてのXML属性は、通常どおり解析対象属性になります。タグ名自体は無視されます。たとえば、リストに属性名のMoeおよびLarryがこの順序で含まれます。元のファイルにはXMLタグのStoogesが含まれ、そのタグには属性Moe、LarryおよびCurlyがあります。区切られたリストでMoeが最初に表示されるため、その値、leaderは解析対象コンテナ名になります。LarryおよびCurlyは解析対象属性になります。タグ名Stoogesは無視されます。元のXMLフラグメントは次のようになります。 <?xml version="1.0" encoding="UTF-8"?> <Comedy> <Stooges Moe="leader", Larry="zany", Curly="bald"> </Stooges> </Comedy>

MULTIKEY_DELIMITER

CONTAINER_NAMEパラメータでXML属性名のリストを区切るデリミタ。デフォルト: チルダ(~)

STORE_CONTENT_AS

要素にXML属性が含まれる場合に、要素テキスト・コンテンツから取得される、解析対象属性に付与される名前。デフォルト: text_value

CONTAINER_NAME

MULTIKEY_DELIMITERパラメータの値で区切られるXML属性名のリスト。このリストの属性名が元のファイルのタグに表示される場合、タグはXML属性の値で名付けられたコンテナになります。その他のすべてのXML属性は、通常どおり解析対象属性になります。タグ名自体は無視されます。

たとえば、リストに属性名のMoeおよびLarryがこの順序で含まれます。元のファイルにはXMLタグのStoogesが含まれ、そのタグには属性Moe、LarryおよびCurlyがあります。区切られたリストでMoeが最初に表示されるため、その値、leaderは解析対象コンテナ名になります。LarryおよびCurlyは解析対象属性になります。タグ名Stoogesは無視されます。元のXMLフラグメントは次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<Comedy>
   <Stooges Moe="leader", Larry="zany", Curly="bald">
   </Stooges>
</Comedy>

WebLogic属性キー・パーサー

Cloud Controlは、WebLogic config.xmlを解析するように特殊設計されたOracleが提供する属性キー・パーサーを提供します。これはデフォルトXMLパーサーと同じパラメータを保有し、同じ名前のノードを一意に特定するための26のデフォルト解析後ルールを備えています。

WebSphere属性キー・パーサー

Cloud Controlは、特定のWebSphere構成ファイルを解析するように設計されたOracleが提供するいくつかの属性キー・パーサーを提供します。各パーサーはデフォルトXMLパーサーと同じパラメータを保有し、同じ名前のノードを一意に特定するための一連のデフォルト解析後ルールを備えています。次のWebSphere構成ファイルのためのパーサーがあります。

node.xml (1つのデフォルト解析後ルール)
plugin-cfg.xml (7つのデフォルト解析後ルール)
resource.xml (9つのデフォルト解析後ルール)
server.xml (13のデフォルト解析後ルール)
variables.xml (1つのデフォルト解析後ルール)

汎用XMLパーサーについて

解析は次のように行われます。

すべてのXML要素がコンテナになります。
すべてのXML属性は解析対象属性になります。
要素テキスト・コンテンツは名前text_valueを取得する解析対象属性になり、ここでテキスト・コンテンツは解析対象属性値になります。

汎用XMLパーサーはパラメータを受け入れません。

WebSphere汎用パーサー

Cloud Controlは、WebSphere serverindex.xml構成ファイルを解析するように設計されたOracleが提供する1つの汎用パーサーを提供します。これは同じ名前のノードを一意に特定するための3つのデフォルト解析後ルールを備えています。

XMLパーサーの例

この項には、3つのXMLパーサーの例が記載されています。

Oracleが提供するパラメータ値を使用して、デフォルトのXMLパーサーを使用して解析する場合
変更されたパラメータ値とともにデフォルトXMLパーサーを使用して解析される場合
汎用XMLパーサーを使用して解析される場合

解析例は次のような元のXMLファイルから導かれます。

  <?xml version="1.0" encoding="UTF-8"?>
  <Application>
     <AppName>foo</AppName>
     <Server name="ajax" os="linux">production</Server>
  </Application>

デフォルトのXMLパーサー(Oracleにより提供されたパラメータ値)

Oracleが提供するパラメータ値を使用して、デフォルトのXMLパーサーを使用して解析すると、解析されたバージョンは次のように表示されます。

  Application
     AppName = foo  
     Server 
        name = ajax
        os = linux
        text_value = production

この解析後バージョンでは次の点に注意してください。

AppNameタグおよびServerタグの要素コンテンツが解析対象属性になります。
AppNameタグにXML属性が含まれていないため、解析対象属性名はタグ名を取得します。
XML属性(nameおよびos)を持つServerタグとの対比。ここではタグで名付けられたコンテナ(Server)が生成されます。これには3つの解析対象属性があり、この中の2つは2つのXML属性に対するものです。もう1つはServerタグのテキスト・コンテンツに対するもので、これはSTORE_CONTENT_ASパラメータの値(text_value)に設定されます。

デフォルトXMLパーサー(変更されたパラメータ値)

パラメータ値を変更するには新規パーサーを作成する必要があります。これにはデフォルトXMLパーサーのエクスポート、エクスポートされたXMLファイルの変更、および変更されたパーサーの(新規の名前およびパーサーIDを使用した)インポートが必要です。

このプロセスに従い、次の変更を行ったと仮定します。

STORE_CONTENT_ASパラメータを値myValに設定
CONTAINER_NAMEパラメータを値nameに設定

変更されたパラメータ値とともにデフォルトXMLパーサーを使用して解析される場合、解析後バージョンは次のように表示されます。

  Application
     AppName = foo  
     ajax 
        os = linux
        myVal = production

この解析後バージョンでは次の点に注意してください。

AppNameタグはそのまま同じです。つまり、XML属性がないため、解析対象属性になります。
ServerタグにはCONTAINER_NAMEの値に一致するXML属性があるため、コンテナは属性の値(ajax)を取得し、name=ajax解析対象属性が不要になります。Oracleが提供するCONTAINER_NAMEパラメータには、実際のデフォルト値を持たないプレースホルダが含まれているため、このバージョンの解析後の表現に違いがあります。
残りのServerタグ属性(os)は通常どおり解析対象属性になります。タグに関連付けられたテキスト・コンテンツは、編集されたSTORE_CONTENT_ASパラメータごとに、属性myValの値になります。

汎用XMLパーサー

(パラメータをまったく使用しない)汎用XMLパーサーを使用して解析される場合、解析後バージョンは次のように表示されます。

  Application
     AppName 
        text_value = foo
     Server 
        name = ajax
        os = linux
        text_value = production

解析手順については「デフォルトXMLパーサーについて」を参照してください。

フォーマット固有のパーサーについて

フォーマット固有のベース・パーサーは、特定のデータ・フォーマットにのみ適用可能です。フォーマット固有のパーサーは、フォーマットを調整するパラメータがまったくないものから、少しあるもの、多数あるものまで様々です。

パーサー	説明
Blue Martini DNA	Blue Martini DNAファイル用のパーサー(パラメータなし)。
Connect:Direct	Connect:Direct `.cfg`ファイル用のパーサー(パラメータなし)。
データベース問合せ(例については「SQL問合せの解析およびルール適用の例」を参照)	構成拡張のデータベース問合せ出力用のパーサー。Cloud Controlは、問合せ結果をパーサーが受入れできる形式に自動的に変換し、Windowsの`.ini`ファイルと同様に結果をセクションに編成します。各セクションは1レコードを表し、セクション内の各行には表列名と値が含まれます。詳細は、「データベース問合せパーサーのパラメータ」を参照してください。
データベース問合せペア列	構成拡張のデータベース問合せ出力用のパーサー。Cloud Controlは、問合せ結果をパーサーが受入れできる形式に自動的に変換し、Windowsの.iniファイルと同様に結果をセクションに編成します。各セクションは1レコードを表し、セクション内の各行には、名前と値が含まれています(名前と値は、返された列の値です)。このように、パーサーがデータを解析するためには、問合せから偶数の列が返される必要があります。奇数の列を返す問合せは、解析エラーになります。データベース問合せペア列パーサーのパラメータを参照してください。
Db2	DB2 `GET DATABASE CONFIGURATION`コマンドの出力用のパーサー(パラメータなし)。
ディレクトリ	同じ行に複数の名前と値のペアが含まれる(つまり、各行に様々な数のペアが含まれる)ファイル用のパーサー。たとえば、第1行がa=b j=k、第2行がc=d m=n y=zのような場合です。詳細は、「ディレクトリ・パーサーのパラメータ」を参照してください。
E-Business Suite	E-Business Suite `.drv`ファイル用のパーサー。パーサーはファイル内の`IF...THEN...ELSE`構造を解析対象の表現内のコンテナに変換して、残りの行を固定された数の解析対象属性があるコンテナに変換します。これらの行は2種類に分けられます。解析対象属性の名前が`DIR_HEADER`パーサー・パラメータで指定されているディレクトリ仕様と、解析対象属性の名前が`HEADER`パーサー・パラメータで指定されている構成ファイル仕様です。詳細は、「E-Business Suiteパーサーのパラメータ」を参照してください。
Galaxy CFG	Galaxy `.cfg`ファイル用のパーサー。詳細は、「Galaxy CFGパーサーのパラメータ」を参照してください。
Introscope	Introscopeファイル用のパーサー(パラメータなし)。
MQ-Series	MQ-Seriesファイル用のパーサー。詳細は、「MQ-Seriesパーサーのパラメータ」を参照してください。
Odin	Odinファイル用のパーサー(パラメータなし)。
Oracle ORA	`tnsnames.ora`などのOracle `.ora`ファイル用のパーサー(パラメータなし)。
Siebel	Siebel `siebns`ファイル用のパーサー。パーサーはファイル内の一意の各パスに対するコンテナと、名前と値のペアに対する属性を作成します。ただし、行に文字列`Type=empty`が含まれる場合は例外で、この場合、パーサーは行に対して解析対象属性を作成しません。詳細は、「Siebelパーサーのパラメータ」を参照してください。
UbbConfig	BEA Tuxedoファイル用のパーサー(パラメータなし)。パーサーは先頭にアスタリスク(*)があるセクションと、新規行の最初にある二重引用符で囲まれた名前を、コンテナに変換します。その他のすべてのデータを属性に変換します。
Unix Installed Patches	UNIXインストール済パッチ・データ用のパーサー。パーサーはファイルの(コメント行ではない)各行ごとに1つのコンテナを作成します。パーサーは、各行でコロン(:)で終了するすべてのフィールドをプロパティ名フィールドとして扱い、それに続く値(がある場合)はプロパティ値として扱います。プロパティには値が必ずしも必要ではありません。詳細は、「UNIXインストール済パッチ・パーサーのパラメータ」を参照してください。
UNIX再帰的ディレクトリ・リスティング	UNIX再帰的ディレクトリ・リスティング(`ls -l -R`)の出力用のパーサー。パーサーは各サブディレクトリ行をコンテナに変換して、各ファイル情報の行を固定された一連の属性があるコンテナに変換します。「UNIX再帰的ディレクトリ・リスティング・パーサーのパラメータ」を参照してください。

フォーマット固有のパーサーを変更するには新規パーサーを作成する必要があります。これには特定のパーサーのエクスポート、エクスポートされたXMLファイルの変更、および変更されたパーサーの(新規の名前およびパーサーIDを使用した)インポートが必要です。

データベース問合せパーサーのパラメータ

次の表で、データベース問合せパーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ	説明
`CELL_DELIMITER`	名前と値のペアを区切る文字。デフォルトは=です。
`PROPERTY_DELIMITER`	名前または値の長さを値そのものから区切る文字。デフォルトは_です。
`COMMENT`	次に続く行を無視するようにパーサーに伝える文字。デフォルトは#です。
`SECTION_START`	セクションの開始を示す文字。デフォルトは\[です(バックスラッシュはエスケープ文字です)。
`SECTION_END`	セクションの終了を示す文字。デフォルトは\]です(バックスラッシュはエスケープ文字です)。
`USE_INI_SECTION`	Windows `.ini`タイプ・セクションを使用するようにパーサーに伝えるフラグ。デフォルトはtrueです。

データベース問合せペア列パーサーのパラメータ

次の表で、データベース問合せパーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ	説明
`CELL_DELIMITER`	名前と値のペアを区切る文字。デフォルトは=です。
`PROPERTY_DELIMITER`	名前または値の長さを値そのものから区切る文字。デフォルトは_です。
`COMMENT`	次に続く行を無視するようにパーサーに伝える文字。デフォルトは#です。
`SECTION_START`	セクションの開始を示す文字。デフォルトは\[です(バックスラッシュはエスケープ文字です)。
`SECTION_END`	セクションの終了を示す文字。デフォルトは\]です(バックスラッシュはエスケープ文字です)。
`USE_INI_SECTION`	Windows `.ini`タイプ・セクションを使用するようにパーサーに伝えるフラグ。デフォルトはtrueです。

ディレクトリ・パーサーのパラメータ

次の表で、ディレクトリ・パーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ	説明
`CELL_DELIMITER`	あるプロパティを別のプロパティと区切る文字。デフォルトはスペースです。
`EXTRA_DELIMITER`	プロパティ名をその値から区切る文字。デフォルトは=です。
`COMMENT`	次に続く行を無視するようにパーサーに伝える文字。デフォルトは#です。

E-Business Suiteパーサーのパラメータ

次の表で、E-Business Suiteパーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ	説明
`DIR_HEADER`	ディレクトリ仕様の属性名のチルダ区切りリスト。
`STRUCTURE_START`	構造の開始を表す正規表現のチルダ区切りリスト。
`CELL_DELIMITER`	名前と値のペア・デリミタを表す正規表現のチルダ区切りリスト。
`HEADER`	ファイル仕様の属性名のチルダ区切りリスト。
`COMMENT`	コメントを表す正規表現のチルダ区切りリスト。
`STRUCTURE_END`	構造の終了を表す正規表現のチルダ区切りリスト。
`LAST_FREE_FORM`	ディレクトリ仕様またはファイル仕様の最後の値のセル・デリミタを無視するようにパーサーに伝えるフラグ。デフォルトはtrueです。
`ELEMENT_FIELD`	ファイル仕様の属性名のチルダ区切りリスト。パーサーは指定された属性の値を連結して、ファイル仕様に関連付けられたコンテナの名前を生成します。
`DIR_ELEMENT_FIELD`	ディレクトリ仕様に関連付けられたコンテナの名前を決定する際にパーサーで使用される、ディレクトリ仕様の属性名のチルダ区切りリスト。

Galaxy CFGパーサーのパラメータ

次の表で、Galaxy CFGパーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ	説明
`COMMENT`	次に続く行を無視するようにパーサーに伝える文字。デフォルトは!です。
`ADD_SUFFIX`	コンテナ名に追加する値を保有する属性の名前。
`MONO_PROP_SECTION`	単一のプロパティを持つセクションの名前。
`MULTI_PROP_SECTION`	複数のプロパティを持つセクションの名前。
`NODES_SECTION`	セクションの開始および終了要素の名前

MQ-Seriesパーサーのパラメータ

MQ-Seriesパーサーのカスタマイズ可能なパラメータはCOMMENTの1つのみで、このデフォルト値は*です。

Siebelパーサーのパラメータ

次の表で、Siebelパーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ	説明
`LINES_TO_SKIP`	ファイルの開始時に無視する行数をパーサーに伝えます。デフォルトは4です。
`CELL_DELIMITER`	名前と値のペア・デリミタを表す正規表現のチルダ区切りリスト。
`COMMENT`	コメントを表す正規表現のチルダ区切りリスト。
`SECTION_START`	一意のパス仕様セクションの開始を表す正規表現のチルダ区切りリスト。
`SECTION_END`	一意のパス仕様セクションの終了を表す正規表現のチルダ区切りリスト。
`USE_INI_SECTION`	Windows `.ini`タイプ・セクションを使用するようにパーサーに伝えるフラグ。デフォルトはtrueです。

UNIXインストール済パッチ・パーサーのパラメータ

次の表で、UNIXインストール済パッチ・パーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ	説明
`CELL_DELIMITER`	名前と値のペアを区切る文字。デフォルトはスペースです。
`EXTRA_DELIMITER`	プロパティ名をその値から区切る文字。デフォルトは:です。
`COMMENT`	次に続く行を無視するようにパーサーに伝える文字。デフォルトは#です。

UNIX再帰的ディレクトリ・リスティング・パーサーのパラメータ

次の表で、UNIX再帰的ディレクトリ・リスティング・パーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ	説明
`LINES_TO_SKIP`	ファイルの開始時に無視する行数をパーサーに伝えます。デフォルトは4です。
`CELL_DELIMITER`	名前と値のペア・デリミタを表す正規表現のチルダ区切りリスト。
`COMMENT`	コメントを表す正規表現のチルダ区切りリスト。
`HEADER`	属性名のチルダ区切りリスト。
`LAST_FREE_FORM`	行の最後の値のセル・デリミタを無視するようにパーサーに伝えるフラグ。デフォルトはtrueです。
`SECTION_START`	サブディレクトリ・セクションの開始を表す正規表現のチルダ区切りリスト。
`SECTION_END`	サブディレクトリ・セクションの終了を表す正規表現のチルダ区切りリスト。
`ELEMENT_FIELD`	属性名のチルダ区切りリスト。パーサーは指定された属性の値を連結して、行に関連付けられたコンテナの名前を生成します。

列指向パーサーについて

列指向パーサーは、フォーマットの調整のために受け入れるパラメータによって、本質的に柔軟性があります。すべての列指向パーサーは、同じパラメータのサブセットを使用します。

パーサー	説明
Cron Access	`cron.allow`ファイルおよび`cron.deny`ファイル用のパーサー。
Cron Directory	UNIXの`etc`ファイルおよび`cron.d`ファイル用のパーサー。
CSV	カンマ区切り値(CSV)データ用のパーサー。 CSVパーサーの列数は不明であるため、Oracleが提供するCSVパーサーを新しいCSVパーサーのテンプレートとして使用します。提供されたCSVパーサーをエクスポートし、パラメータを更新し、目的のフォーマットに合せた新しいCSVパーサーを再インポートします。 Oracleにより提供されるパラメータ値は、次の特性を持つCSVファイルをサポートします。各行に同じ数の値があります。最初に解析された行(つまり、非コメント行)がヘッダー行で、そのコンテンツが列名のカンマ区切り値リストです。二重引用符で囲まれたカンマは値のデリミタではなく、値の一部とみなされます。列名の1つが"name"で、この値が各行に関連付けられたコンテナの名前になります。二重引用符で囲まれたテキストは値の一部とみなされます。二重引用符が含まれる値を指定する場合は、二重引用符をバックスラッシュ(\)でエスケープします。バックスラッシュ文字そのものをエスケープするには、バックスラッシュを使用します(\\)。
Hosts Access	`hosts.allow`ファイルおよび`hosts.deny`ファイル用のパーサー。
Kernel Modules	`kernel modules`ファイル用のパーサー。
Linux Directory List	Linuxディレクトリ・リスティングのデータ形式(例: `ls -l`コマンドの出力)用のパーサー。
PAM Configuration	`pam.conf`ファイル用のパーサー。
PAM Directory	UNIX `etc/pam.d`ファイル用のパーサー。
Process Local	`process.local`ファイル用のパーサー。
Secure TTY	UNIX `etc/securetty`ファイル用のパーサー。
Solaris Installed Packages	Solarisインストール済パッケージ・ファイル用のパーサー。
Unix Crontab	UNIX Crontabファイル用のパーサー。
Unix Directory List	UNIXディレクトリ・リスティングのデータ形式(例: `ls -l`コマンドの出力)用のパーサー。
Unix Groups	UNIX `etc/group`ファイル用のパーサー。パーサーはグループ名とパスワード情報を無視します。
Unix GShadow	UNIX `etc/gshadow`ファイル用のパーサー。
Unix Hosts	UNIX `etc/hosts`ファイル用のパーサー。
Unix INETD	UNIX `etc/inetd.conf`ファイル用のパーサー。
Unix Passwd	UNIX `etc/passwd`ファイル用のパーサー。パーサーはパスワード値を無視します。
Unix Protocols	UNIX `etc/hosts`ファイル用のパーサー。
Unix Services	UNIX `etc/services.conf`ファイル用のパーサー。
Unix Shadow	UNIX `etc/shadow`ファイル用のパーサー。
Unix System Crontab	UNIXシステムcrontabファイル用のパーサー。システムcrontabファイルはcrontabファイルと非常に似ていますが、`PATH=/a/b`などの名前と値のペアが含まれる場合があります。

列指向パーサーのパラメータ

この項では、すべての列指向ベース・パーサーのパラメータについて説明します。ベース・パーサーは次のどのパラメータの値も受入れできますが、指定されたパーサー仕様はすべてのパラメータの値を必ずしも提供する必要はありません。すべてのパラメータにはデフォルト値があり、これらは指定された値がないときに使用されますが、パラメータに明示的な値がある場合もあります。

デリミタまたはその他の特殊なテキスト(コメント文字や新規行など)がある値の一部を表すときは、引用符を使用します。QUOTE_DELIMITERは使用する文字値を決定します。文字をエスケープする必要がある場合は、引用符デリミタの先頭にバックスラッシュ(\)を追加します。引用された文字列でバックスラッシュ文字そのものをエスケープするには、バックスラッシュを使用します(\\)。

パラメータ	説明
`COMMENT`	コメントの文字またはシーケンスを示す正規表現のチルダ区切りリスト。たとえば、`#[^\r\n]*`は、行の上で#文字に続くすべてがコメントであることを指定します。デフォルトは空のリストです。つまり、すべてのファイル・コンテンツを解析します。
`LINES_TO_SKIP`	解析のために無視し、事実上、コメントとして扱う初期行の数(ブランク行またはコメント行を除く)。デフォルトは0です。つまり、行をスキップしません。
`CELL_DELIMITER`	行の値を区切る正規表現のチルダ区切りリスト。デフォルトは空のリストです。つまり、デリミタはありません(デフォルトを使用することはまれです)。
`QUOTE_DELIMITER`	引用された値の開始および終了方法を定義する正規表現のチルダ区切りリスト(通常は一重引用符または二重引用符のいずれか)。開始および終了の引用符デリミタは同じである必要があります。デフォルトは空のリストです。つまり、パーサーは引用された値を認識しません。
`PROPERTY_DELIMITER`	プロパティの名前と値を区切る正規表現のチルダ区切りリスト。デフォルトは空のリストです。つまり、プロパティ・デリミタはありません。まれに、構文a=bの名前と値のペアが列指向ファイルに含まれる場合があります。
`RESERVED_DIRECTIVES`	プロパティ・キーワードのチルダ区切りリスト。一部のcrontabファイルには、デリミタで区切られた単純な名前と値のペアが含まれます(foo=bar)。したがって、各行に同じ数のフィールドが含まれるという要件に違反します。このパラメータはプロパティ・キーワードを指定するための回避策を提供します。この例では、プロパティ・キーワードはfooになります。つまり実際は、ルート・コンテナ下にある解析対象属性の名前と値のペアとして、このキーワードで始まる行を解析します。デフォルトは空のリストです。つまり、プロパティ・キーワードはありません。
`ALTERNATE_DELIMITER`	プロパティの名前と値に対する代替デリミタ。デフォルトは'/'です(`ALTERNATE_FIELD`パラメータが空ではない場合のみ使用されます)。
`ALTERNATE_FIELD`	代替デリミタで区切られるフィールドのチルダ区切りリスト。デフォルトは空のリストです。つまり、代替デリミタはありません。
`HEADER_FLAG`	列名を示すヘッダー行がファイルに含まれるかどうかを指定するフラグ。デフォルトはfalseです。
`HEADER`	ヘッダー行がない場合に使用する列名のチルダ区切りリスト。デフォルトは空のリストです。つまり、列名はありません(デフォルトを使用することはまれです)。
`ELEMENT_FIELD`	行に関連付けられたコンテナの名前を作成する際にパーサーで連結される値を持つ、列名のチルダ区切りリスト。デフォルトは空のリストです。つまり、列名はありません(デフォルトを使用することはまれです)。
`IGNORE_FIELD`	無視する列名のチルダ区切りリスト。この列の値の解析は行われません。デフォルトは空のリストです。つまり、何も無視されません。
`LAST_FREE_FORM`	最後の列が自由形式かどうかを指定するフラグ。パーサーは自由形式の列値ですべてのデリミタを無視します。デフォルトはfalseです。
`USE_LINE_COMMENT`	データの解析対象の表現に表示される値として、行終了コメントを扱うかどうかを指定するフラグ。デフォルトはfalseです。

プロパティ・パーサーについて

プロパティ・パーサーは、フォーマットの調整のために受け入れ、異なる組織的な要素を処理できるパラメータによって、本質的に柔軟性があります。すべてのプロパティ・パーサーは、基本パラメータおよび拡張パラメータ、さらに拡張構成と同じパラメータ・セットを使用します。

パーサー	説明
AIX Installed Packages	AIXインストール済パッケージ・ファイル用のパーサー。
Apache HTTPD	Apache `HTTPD.conf`ファイル用のパーサー。
Autosys	`Autosys.jil`ファイル用のパーサー。
Custom CFG	カスタム`.cfg`ファイル用のパーサー。この構文は`E = {}`構文のある要素を定義します。ここで中カッコの中には名前と値のペア、ネストされた要素、あるいはその両方が含まれる場合があります。
Java Policy	`java.policy`ファイル用のパーサー。
Java Properties	`java.properties`ファイル用のパーサー。
LDAP	LDAP `.cfg`ファイル用のパーサー。
Mime Types	`mime.types`ファイル用のパーサー。
Radia	Radia `.cfg`ファイル用のパーサー。
Sectioned Properties	セクションに編成されている名前と値のペアが含まれるファイル(Windowsの`.ini`ファイルなど)用のパーサー。
SiteMinder Agent	SiteMinderエージェント・ファイル用のパーサー。
SiteMinder Registry	SiteMinder `.registry`ファイル用のパーサー。
SiteMinder Report	SiteMinder `SmReport.txt`ファイル用のパーサー。
SmWalker	SiteMinder `SmWalker.dat`ファイル用のパーサー。
Sun ONE Magnus	Sun ONE `magnus.conf`ファイル用のパーサー。
Sun ONE Obj	Sun ONE `obj.conf`ファイル用のパーサー。
Tuxedo	Tuxedoファイル用のパーサー。
Unix Config	UNIX `etc/config`ファイル用のパーサー。
Unix Login	UNIX `etc/login.defs`ファイル用のパーサー。
Unix PROFTPD	UNIX `etc/proftpd.conf`ファイル用のパーサー。
Unix Resolve	UNIX `etc/resolve.conf`ファイル用のパーサー。
Unix SSH Config	UNIX `etc/ssh/sshd.conf`ファイル用のパーサー。
Unix System	UNIX `etc/system`ファイル用のパーサー。
Unix VSFTPD	UNIX `etc/vsftpd.conf`ファイル用のパーサー。
Unix XINETD	UNIX `etc/xinetd.conf`ファイル用のパーサー。
WebAgent	WebAgentファイル用のパーサー。
Windows Checksum	`fciv.exe`で生成されたWindowsチェックサム出力用のパーサー。

基本プロパティ・パーサーのパラメータ

この項では、シンプル・プロパティのデータ形式の解析に必要な、基本プロパティ・パーサーのパラメータについて説明します。シンプル・プロパティのデータ形式は、通常は名前と値を区切る定義済のデリミタによって、プロパティを名前と値のペアとして指定します: foo=bar。基本データ形式はプロパティのリストで、1行につき1つのプロパティがオプションのコメントとともにあります。例としてjava.propertiesファイルがあります。すべてのパラメータにはデフォルト値があり、これらは指定された値がないときに使用されます。

ポンド記号(#)などのコメント文字や、特定の文字シーケンス(//)は通常、コメントを示します。Cスタイル・コメント(/*….*/)などの特殊なシーケンスは、コメントの開始および終了を示す場合があります。最初の数行に一般的な情報コンテンツが含まれるファイルもあります。この場合は、対象の行を無視するようにパーサーに伝えるパラメータを使用できます。

パラメータ	説明
`COMMENT`	コメントの文字またはシーケンスを示す正規表現のチルダ区切りリスト。たとえば、`#[^\r\n]*`は、行の上で#文字に続くすべてがコメントであることを指定します。デフォルトは空のリストです。つまり、すべてのファイル・コンテンツを解析します。
`LINES_TO_SKIP`	解析のために無視し、事実上、コメントとして扱う初期行の数(ブランク行またはコメント行を除く)。デフォルトは0です。つまり、行をスキップしません。
`CELL_DELIMITER`	行の値を区切る正規表現のチルダ区切りリスト。デフォルトは空のリストです。つまり、デリミタはありません(デフォルトを使用することはまれです)。
`QUOTE_DELIMITER`	引用された値の開始および終了方法を定義する正規表現のチルダ区切りリスト(通常は一重引用符または二重引用符のいずれか)。開始および終了の引用符デリミタは同じである必要があります。デフォルトは空のリストです。つまり、パーサーは引用された値を認識しません。
`ALLOW_NAME_ONLY_PROPERTIES`	デリミタまたは値のないプロパティ名をパーサーが許可するかどうかを示すフラグ。デフォルトはfalseです。
`REVERSE_PROPERTY`	デリミタおよびプロパティ名の前に存在する値をパーサーが許可するかどうかを示すフラグ。デフォルトはfalseです。

拡張プロパティ・パーサーのパラメータ

この項では、より複雑なプロパティのデータ形式の解析に必要な、拡張プロパティ・パーサーのパラメータについて説明します。すべてのパラメータにはデフォルト値があり、これらは指定された値がないときに使用されます。

パラメータ	説明
`PROPERTY_DELIMITER`	プロパティ・デリミタを表す正規表現のチルダ区切りリスト。たとえば、テキスト"a=b : x=y"は次の2通りに解釈できます。値"b : x=y"を持つ"a"という1つのプロパティ "a=b"と"x=y"という2つの別個のプロパティコロン(:)がプロパティ・デリミタの場合、解析エンジンはこのテキストを、2つのプロパティが含まれるテキストと解釈します。デフォルトは空のリストです。つまり、パーサーはプロパティ・デリミタを認識しません。
`LINE_END_DELIMITER`	行およびシーケンスを表す正規表現のチルダ区切りリスト。パーサーで行終了デリミタが検知されると、新規のプロパティまたは構造が次の行で開始するとみなされます。デフォルトは空のリストです。つまり、パーサーは行終了デリミタを認識しません。
`CONTINUE_LINE`	継続行シーケンスを表す正規表現のチルダ区切りリスト。パーサーで継続行パターンが検知されると、次の行のデータが、前の行の構造またはプロパティの続きとして解釈されます。これは、新規のプロパティまたは構造の開始として新規行が解釈される場合と対照的です。たとえば、複数の行に渡るプロパティ値をパーサーが認識するには、行継続パターンが検知される必要があります。デフォルトは空のリストです。つまり、パーサーは行継続パターンを認識しません。
`SECTION_START`	セクションの開始を表す正規表現のチルダ区切りリスト。セクションはネストできません。デフォルトは空のリストです。つまり、パーサーはセクションを認識しません。
`SECTION_END`	セクションの終了を表す正規表現のチルダ区切りリスト。デフォルトは空のリストです。
`STRUCTURE_START`	構造の開始を表す正規表現のチルダ区切りリスト。構造はネストできません。デフォルトは空のリストです。つまり、パーサーは構造を認識しません。
`STRUCTURE_END`	構造の終了を表す正規表現のチルダ区切りリスト。デフォルトは空のリストです。
`XML_STYLE_TAG`	ファイル内の構造がXMLスタイル・タグかどうかを示すフラグ。デフォルトはfalseです。
`USE_INI_SECTION`	INIスタイル・セクションが存在するかどうかを示すフラグ。デフォルトはfalseです。
`RESERVED_DIRECTIVES`	予約されたディレクティブの開始を示す予約名のチルダ区切りリスト。デフォルトは空のリストです。つまり、パーサーは予約されたディレクティブを認識しません。
`RESERVED_FUNCTIONS`	予約された関数の開始を示す予約名のチルダ区切りリスト。デフォルトは空のリストです。つまり、パーサーは予約された関数を認識しません。
`DIRECTIVE_PROPERTIES`	予約されたディレクティブ - 暗黙的なプロパティ名のチルダ区切りリスト。デフォルトは空のリストです。
`FUNCTION_PROPERTIES`	必須の予約された関数 - 明示的なプロパティ名のチルダ区切りリスト。デフォルトは空のリストです。
`SECTION_PROPERTIES`	セクション - 暗黙的なプロパティ名のチルダ区切りリスト。デフォルトは空のリストです。
`STRUCTURE_PROPERTIES`	構造 - 暗黙的なプロパティ名のチルダ区切りリスト。デフォルトは空のリストです。
`ELEMENT_FIELD`	プロパティの解析時にパーサーで無視されるキーワード。これは一般的に、名前と値のペアの前にキーワードを指定するデータ形式に適用されます。例として、"set a=b"があります。デフォルトは空のリストです。つまり、パーサーでは何も無視されません。
`ALLOW_ELEMENT_CELL`	ファイル形式が要素セル構造をサポートするかどうかを示すフラグ。デフォルトはfalseです。
`SECTION_EXPLICIT_PROPERTIES`	セクションが明示的なプロパティをサポートするかどうかを示すフラグ。デフォルトはfalseです。
`STRUCTURE_EXPLICIT_PROPERTIES`	構造が明示的なプロパティをサポートするかどうかを示すフラグ。デフォルトはfalseです。
`NEWLINE_CONTINUE_LIN`	新規行が行継続シーケンスになるかどうかを示すフラグ。デフォルトはfalseです。
`KEYWORD_FIELD`	空白デリミタを使用するプロパティの前にあるキーワードを表す、正規表現のチルダ区切りリスト。デフォルトは空のリストです。つまり、パーサーはキーワードを認識しません。

拡張プロパティ・パーサーの構成

プロパティ・ファイルは様々なファイル形式で表されます。幅広い範囲の形式に対応するため、汎用プロパティのベース・パーサーはほとんどのファイルで見つかる構成の組合せを使用します。

構成は2つのカテゴリに分類されます。

コンテナ構成: 予約された関数、予約されたディレクティブ、XML構造、構造、区切られた構造、INIセクション、区切られたセクション、セクション、および要素セル
プロパティ構成: シンプル・プロパティ、リバース・プロパティ、キーワード・プロパティ、キーワード名プロパティ、大カッコ・プロパティ、暗黙的なプロパティ、および明示的なプロパティ

要素構成の中で、セクション構成はネストできませんが、その他の構成を含むことはできます。構造構成はネストが可能で、セクション以外のその他の構成を含むことができます。要素セルはネストできますが、要素セルおよびシンプル・プロパティのみを含むことができます。予約されたディレクティブと予約された関数はネストすることも、その他の構成を含むこともできません。

この項では次に、基本プロパティ・パーサーがサポートする構成について説明します。

シンプル・プロパティ

シンプル・プロパティはプロパティ名、セル・デリミタ、プロパティ値および新規行シーケンスでこの順序どおりに構成されます。シンプル・プロパティは複数の行に渡る場合がありますが、複数の行に渡るプロパティには通常、行継続文字またはシーケンスが含まれます。空白に何か意味があるとパラメータで指定(例: セル・デリミタ)されていないかぎり、パーサーはタブやスペースなどの空白を無視します。

たとえば、name=value_that_wraps_to_next_line_/では、フォワード・スラッシュが行継続文字として機能します。Javaプロパティ・ファイルがこのデータ形式の代表的な例です。

キーワード・プロパティ

この構成はシンプル・プロパティとほとんど同じで、キーワードが先頭にありますがこれはパーサーで無視されます。

たとえば、set name=valueでは、setが無視されるキーワードです。UNIXシステム・ファイルがこのデータ形式の代表的な例です。

キーワード名プロパティ

この構成は、プロパティ名がKEYWORD_FIELDパーサー・パラメータで指定される正規表現に一致する、シンプル・プロパティです。これはUNIX XINETDパーサーに固有の、特殊なケースのプロパティ・タイプです。XINETDファイルは等記号(=)をセル・デリミタとして使用します。ただし、プロパティがキーワード"include"または"includedir"で始まる場合は、セル・デリミタが空白となるので例外です。

特にXINETDファイルに対して追加されますが、適切な場合はその他のファイル・タイプにもプロパティを使用できます。

たとえば、includedir /etcでは、includedirがパーサー・パラメータの正規表現で、空白がセル・デリミタです。

明示的なプロパティ

明示的なプロパティはプロパティ名、デリミタおよびプロパティ値で構成されます。シンプル・プロパティまたはキーワード・プロパティと異なり、明示的なプロパティはセクションまたは構造などのコンテナ構成に制限されます。例として、XMLタグ属性があります。

例

[SectionName p1=v1 p2=v2]

<StructureName p1=v1 p2=v2>
...
</StructureName>

これらの構成では、p1 v1とp2 v2の名前と値のペアが明示的なプロパティです。Sun ONE Objファイルがこのデータ形式の代表的な例です。

暗黙的なプロパティ

暗黙的なプロパティは、関連付けられたプロパティ名がないプロパティ値です。明示的なプロパティと同様に、暗黙的なプロパティはコンテナ構成(通常は予約されたディレクティブ)に制限されます。DIRECTIVE_PROPERTIESパーサー・パラメータには暗黙的なプロパティのプロパティ名が含まれます。

例

[SectionName myName myPath]

<StructureName myName myPath>
...
</StructureName>

これらの構成で、DIRECTIVE_PROPERTIESパーサー・パラメータで宣言されたとおり、推定されたプロパティ名のnameおよびpathとともに、暗黙的なプロパティはmyNameおよびmyPathという値を持ちます。Apache HTTPDファイルがこのデータ形式の代表的な例です。

予約された関数

予約された関数は、明示的なプロパティが1つ以上後ろに続くキーワードです。RESERVED_FUNCTIONSパーサー・パラメータは、予約された関数を表すキーワードを指定します。

たとえば、Error fn="query-handler" type="forbidden"では、RESERVED_FUNCTIONSパーサー・パラメータで指定される予約された関数のキーワードはErrorです。Sun ONE Magnusファイルがこのデータ形式の代表的な例です。

予約されたディレクティブ

予約されたディレクティブは、暗黙的なプロパティが1つ以上後ろに続くキーワードです。RESERVED_DIRECTIVESパーサー・パラメータは、予約されたディレクティブを表すキーワードを指定します。

たとえば、LoadModule cgi_module "/bin/modules/std/cgi"では、RESERVED_DIRECTIVESパーサー・パラメータで指定される予約された関数のキーワードはLoadModuleです。Apache HTTPDファイルがこのデータ形式の代表的な例です。

XML構造

XML構造は標準的なXMLタグで、名前のみ、明示的なプロパティが後ろに続く名前、または暗黙的なプロパティが後ろに続く名前を含むことができます。

例

<Name>
...
</Name>

<Name p1=v1 p2=v2>
...
</Name>
<Name "implicit_property1" "implicit_property2">
...
</Name>

WebAgentファイルがこのデータ形式の代表的な例です。

区切られた構造

区切られた構造は、次の要素で(指定された順序で)構成されます。

構造名
区切り記号
開始構造文字または文字シーケンス
構造コンテンツ
終了構造文字または文字シーケンス

例:

StructureName = {
...
}

明示的および暗黙的なプロパティは使用できません。Javaポリシー・ファイルとCustom CFGファイルがこのデータ形式の代表的な例です。

構造

構造は、次の要素で(指定された順序で)構成されます。

構造名
開始構造文字または文字シーケンス
構造コンテンツ
終了構造文字または文字シーケンス

区切られた構造と構造の違いはデリミタのみです。つまり、構造では、構造名と開始構造インジケータの間にデリミタは不要です。

例:

StructureName {
...
}

明示的および暗黙的なプロパティは使用できません。UNIX XINETDファイルがこのデータ形式の代表的な例です。

INIセクション

INIセクションはWindows .iniファイルのセクション見出しに似ており、次のような特徴があります。

セクション開始文字または文字シーケンス
セクション名
オプション(明示的および暗黙的)プロパティ
セクション終了文字または文字シーケンス

例

[SectionName]

[SectionName p1=v1 p2=v2]

[SectionName "implicit_property1" "implicit_ property2"]

SmWalkerファイルとセクション・プロパティ・ファイルがこのデータ形式の代表的な例です。

区切られたセクション

区切られたセクションは共通パターンで開始する行ですが、他の点ではシンプル・プロパティに似ています。

例

HKEY_LOCAL_MACHINE\SOFTWARE\A\B\C=789

HKEY_LOCAL_MACHINE\SOFTWARE\X\Y\Z=123

これらは、共通パターンがHKEY_の、2つの区切られたセクション見出しです。SiteMinder RegistryファイルとLDAPファイルがこのデータ形式の代表的な例です。

要素セル

要素セルは、A = B = Cというフォームの、要素セル名とプロパティ名の名前と値のペアで構成されます。要素セルは通常、行継続シーケンスとネストを使用して構造を明確にします。複数のプロパティを持つ要素セルは、プロパティ・デリミタを使用してプロパティを区切ります。

例1:

EC = \
    B = C, D = F

この例はECという名前の要素セルで、B = CとD = Fの2つのプロパティの名前と値のペアがカンマで区切られます。構造はバックスラッシュ文字(\)を使用して行継続を示します。拡張プロパティのパーサー・パラメータのPROPERTY_DELIMITERおよびCONTINUE_LINEは、個々のフォーマット文字を定義します。

例2:

この例はECという名前の要素セルで、EC2というネストされた要素セルを持ち、A = BとC = Dの2つのプロパティの名前と値のペアが含まれます。この例は同じデリミタと行継続文字を使用します。

解析されたファイルおよびルールの使用

収集された構成ファイルは、RAWフォームでRAW形式で格納され、パーサーが指定されている場合は、ノード、コンテナ、属性またはプロパティのツリー構造に格納されます。このファイルはまた、XPath条件および式で構成された解析後のルールを適用することを目的として内部的にXML形式でも生成されます。この内部形式には、XML以外のファイルも生成されます。この内部形式は、他のファイル・タイプにも対応する必要があるため、属性名および名前しかないJavaプロパティ・ファイルなどのファイルを償うためにXMLに別のルート・ノードを導入します。

次を参照すると、ファイルの解析および表示方法の例と解析後のルールの効果が明らかになります。

XMLファイルの解析およびルール適用の例

次の簡単なXMLファイルについて検討してください。

  <dir name="/a/b/c">    
    <file name="file1" size=120/>    
    <file name="file2" size=350/>    
  </dir>

デフォルトのXMLパーサーを使用して解析された形式が、ユーザー・インタフェースに次のツリー構造で表示されます。

  dir
     	name    = /a/b/c
        file
                name = file1
                size = 120
        file
                name = file2
                size = 350

2つのコンテナの名前(file)が同じであるため、少なくともコンテナ・レベルでは2つを区別できません。このため、このファイルは解析後のルールの候補です。前述のとおり、ルールのXPath条件および式の適用対象である特別な内部XML形式があります。この形式では、ノードおよび属性がXML要素として処理され、属性値が対応する要素テキスト・コンテンツに変換されます。また、元のファイルに表示されないルート要素も追加されます。

  <root>  
    <dir>
        <name>/a/b/c</name>
        <file>
              <name>file1</name>
              <size>120</size>
        </file>
        <file>
              <name>file2</name>
              <size>350</size>
        </file>
    </dir>
  </root>

同じ名前のコンテナが2つある解析された形式の問題がある場合、ルール解決を次で構成することもできます。

条件: /root/dir/file
式: name/text()

この場合、事実上、ファイルごとにname/text()が評価され、dirノード内のファイルを区別する識別子を生成されます。

解析後のルールを適用した後、解析されたツリー構造は次のようになります。

  dir
        name = /a/b/c
        file[file1]
              name = file1
              size = 120
        file[file2]
              name = file2
              size = 350

ルールは、大カッコで囲まれてコンテナ名に追加された識別子に解決されます。この組合せ(file [file1]など)により、比較、検索、変更履歴などの様々な操作でファイル・コンテナを区別できます。

XML以外のファイルの解析およびルール適用の例

次の簡単なORAファイルについて検討してください。

  acme=
     (DESCRIPTION=
        (SOURCE_ROUTE=yes)
        (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1630))
        (ADDRESS_LIST=
           (FAILOVER=on)
           (LOAD_BALANCE=off)
     (ADDRESS=(PROTOCOL=tcp)(HOST=host2a)(PORT=1630))
           (ADDRESS=(PROTOCOL=tcp)(HOST=host2b)(PORT=1630)))
        (ADDRESS=(PROTOCOL=tcp)(HOST=host3)(PORT=1630))
        (CONNECT_DATA=(SERVICE_NAME=xyz.example.com)))

Oracle ORAパーサーを使用して解析された形式が、ユーザー・インタフェースに次のツリー構造で表示されます。

  acme
          DESCRIPTION
               SOURCE_ROUTE    yes
               ADDRESS
                       PROTOCOL         tcp
                       HOST             host1
                       PORT             1630
               ADDRESS_LIST
                       FAILOVER         on
                       LOAD_BALANCE     off
                       ADDRESS
                               PROTOCOL          tcp
                               HOST              host2a
                               PORT              1630
                       ADDRESS
                               PROTOCOL          tcp
                               HOST              host2b
                               PORT              1630
               ADDRESS
                       PROTOCOL         tcp
                       HOST             host3
                       PORT             1630
               CONNECT_DATA
                       SERVICE_NAME     xyz.example.com

スタンドアロンでもADDRESS_LIST内でも、アドレス・コンテナは区別できません。このため、このファイルは解析後のルールの候補です。前述のとおり、ルールのXPath条件および式の適用対象である特別な内部XML形式があります。この形式では、ノードおよび属性がXML要素として処理され、属性値が対応する要素テキスト・コンテンツに変換されます。また、元のファイルに表示されないルート要素も追加されます。

  <root>
          <acme>
                  <DESCRIPTION>
                          <SOURCE_ROUTE>yes</SOURCE_ROUTE>
                          <ADDRESS>
                                  <PROTOCOL>tcp</PROTOCOL>
                                  <HOST>host1</HOST>
                                  <PORT>1630</PORT>
                          </ADDRESS>
                          <ADDRESS_LIST>
                                  <FAILOVER>on</FAILOVER>
                                  <LOAD_BALANCE>off</LOAD_BALANCE>
                                  <ADDRESS>
                                          <PROTOCOL>tcp</PROTOCOL>
                                          <HOST>host2a</HOST>
                                          <PORT>1630</PORT>
                                  </ADDRESS>
                                  <ADDRESS>
                                          <PROTOCOL>tcp</PROTOCOL>
                                          <HOST>host2b</HOST>
                                          <PORT>1630</PORT>
                                  </ADDRESS>
                          </ADDRESS_LIST>
                          <ADDRESS>
                                  <PROTOCOL>tcp</PROTOCOL>
                                  <HOST>host3</HOST>
                                  <PORT>1630</PORT>
                          </ADDRESS>
                          <CONNECT_DATA>
                                  <SERVICE_NAME>xyz.example.com</SERVICE_NAME>
                          </CONNECT_DATA>
                  </DESCRIPTION>
          </acme>
  </root>

同じ名前のコンテナがある解析された形式の問題がある場合、ルール解決を次で構成することもできます。

条件: //ADDRESS
式: /HOST/text()

この場合、事実上、アドレス要素ごとに/HOST/text()が評価され、ホスト名がアドレス識別子として抽出されます。

解析後のルールを適用した後、解析されたツリー構造は次のようになります。

  acme
          DESCRIPTION
               SOURCE_ROUTE    yes
               ADDRESS[host1]
                       PROTOCOL         tcp
                       HOST             host1
                       PORT             1630
               ADDRESS_LIST
                       FAILOVER         on
                       LOAD_BALANCE     off
                       ADDRESS[host2a]
                               PROTOCOL          tcp
                               HOST              host2a
                               PORT              1630
                       ADDRESS[host2b]
                               PROTOCOL          tcp
                               HOST              host2b
                               PORT              1630
               ADDRESS[host3]
                       PROTOCOL         tcp
                       HOST             host3
                       PORT             1630
               CONNECT_DATA
                       SERVICE_NAME     xyz.example.com

ルールは、大カッコで囲まれてコンテナ名に追加された識別子に解決されます。この組合せ(ADDRESS [host2a]など)により、比較、検索、変更履歴などの様々な操作でアドレス・コンテナを区別できます。

SQL問合せの解析およびルール適用の例

次の3列のデータベース表SERVER_DETAILSについて検討してください。

SERVER_NAME	ENVIRONMENT	HOSTED_APPLICATIONS
webserver-100	QA	5
webserver-200	PERFORMANCE	6
webserver-500	PRODUCTION	3

構成拡張作成の一部として表されたSQL問合せは、次のとおりです。

select * from SERVER_DETAILS

この問合せでは、次のようなRAW出力が戻されます。

  [row]
  11_SERVER_NAME=13_ webserver-100
  11_ENVIRONMENT=2_ QA
  19_HOSTED_APPLICATIONS=1_5
  [row]
  11_SERVER_NAME=13_ webserver-200
  11_ENVIRONMENT=11_ PERFORMANCE
  19_HOSTED_APPLICATIONS=1_6
  [row]
  11_SERVER_NAME=13_ webserver-500
  11_ENVIRONMENT=10_ PRODUCTION
  19_HOSTED_APPLICATIONS=1_3

コンフィグレーション・ブラウザ・ソース・タブでも、データは同じようにレンダリングされます。

データベース問合せパーサーを使用して解析された形式が、ユーザー・インタフェースに次のツリー構造で表示されます。

  row
         SERVER_NAME=webserver-100
         ENVIRONMENT=QA
         HOSTED_APPLICATIONS=5
  row
         SERVER_NAME=webserver-200
         ENVIRONMENT=PERFORMANCE
         HOSTED_APPLICATIONS=6
  row
         SERVER_NAME=webserver-500
         ENVIRONMENT=PRODUCTION
         HOSTED_APPLICATIONS=3

rowコンテナは区別できません。このため、この問合せ結果は解析後のルールの候補です。前述のとおり、ルールのXPath条件および式の適用対象である特別な内部XML形式があります。この形式では、ノードおよび属性がXML要素として処理され、属性値が対応する要素テキスト・コンテンツに変換されます。また、元のファイルに表示されないルート要素も追加されます。

  <root>
              <row>
                          <SERVER_NAME>webserver-100</SERVER_NAME>
                          <ENVIRONMENT>QA</ENVIRONMENT>
                          <HOSTED_APPLICATIONS>5</HOSTED_APPLICATIONS>
              </row>
              <row>
                          <SERVER_NAME>webserver-200</SERVER_NAME>
                          <ENVIRONMENT>PERFORMANCE</ENVIRONMENT>
                          <HOSTED_APPLICATIONS>6</HOSTED_APPLICATIONS>
              </row>
              <row>
                          <SERVER_NAME>webserver-500</SERVER_NAME>
                          <ENVIRONMENT>PRODUCTION</ENVIRONMENT>
                          <HOSTED_APPLICATIONS>3</HOSTED_APPLICATIONS>
              </row>
  </root>

同じ名前のコンテナが3つある解析された形式の問題がある場合、ルール解決を次で構成することもできます。

条件: /root/row/SERVER_NAME
式: SERVER_NAME/text()

この場合、事実上、行ごとにSERVER_NAME/text()が評価され、ツリー構造内の行を区別する識別子が生成されます。

解析後のルールを適用した後、解析されたツリー構造は次のようになります。

  row[webserver-100]
         SERVER_NAME=webserver-100
         ENVIRONMENT=QA
         HOSTED_APPLICATIONS=5
  row[webserver-200]
         SERVER_NAME=webserver-200
         ENVIRONMENT=PERFORMANCE
         HOSTED_APPLICATIONS=6
  row[webserver-500]
         SERVER_NAME=webserver-500
         ENVIRONMENT=PRODUCTION
         HOSTED_APPLICATIONS=3

ルールは、大カッコで囲まれてコンテナ名に追加された識別子に解決されます。この組合せ(row[webserver-100]など)により、比較、検索、変更履歴などの様々な操作で行コンテナを区別できます。