GDL 構成の競合を解決する

GDL パーサーは、制約に違反しないように構成を自動的に変更しますが、パーサーが意図を認識できるように、次の情報に留意してください。

たとえば、パーサー関数に渡される構成に Weather.Rain、Today.Sunday、Health.Well のパラメーター設定が含まれている場合、前のセクションの無効な組み合わせは、この制約で指定されているパラメーターのいずれかの設定を変更することで解決できます。 パーサーは、変更するパラメーターの設定を決定する必要があります。 多くの場合、どの設定を変更する必要があるかわかるでしょう。 通常、より重要なパラメーターは変更されません。 この場合、パラメーターをそれぞれ Weather:Sunny、Today:Monday、Health:Sick に変更することで、競合を解決できます。 ほとんどの人は、最初に Weather、2 番目に Today を変更することを好み、Health の変化は避けることを望みます。

*ConflictPriority ディレクティブを使用すると、競合で変更するパラメーターに関する基本設定を指定できます。 *ConflictPriority は、各パラメーターの相対的な重要度を指定する正の整数値を受け入れます。 2 つ以上のパラメーターが競合する場合、パーサーは優先順位の低いパラメーターのパラメーター設定を変更します。 このディレクティブは、最も優先度の高い項目に最も小さい序数でラベル付けする一般的な使用法に準拠しています。 したがって、優先度が最も高いパラメーターには *ConflictPriority: 1 を割り当てる必要があります。 *ConflictPriority: に選択されている値は連続する必要はありませんが、一意である必要があります。 *ConflictPriority は、*Feature コンストラクトの子エントリとして表示されます。

*FeatureType ディレクティブは、パラメーターの優先順位にも影響します。 *FeatureType は、実際には GPD/Unidrv 固有のキーワードです。 Unidrv 以外のクライアントの場合は、単に *FeatureType: PARAMETER_PROPERTY を設定する必要があります。 この設定により、今後予期しない動作が回避されます。 *FeatureType は、*Feature コンストラクトの子エントリとして表示されます。

競合を解決するために GDL がパラメーターの設定を変更すると、制約がない限り、既定の設定が使用されます。 場合によっては、異なる構成で競合を解決するときに、パーサーで別の既定の設定を使用した方がよい場合があります。 このような別の既定の設定を設定するには、Switch ディレクティブと Case ディレクティブ内、または入れ子になった Switch Case ディレクティブのセット内で、複数の *DefaultOption ディレクティブを定義します。 パーサーは、現在の構成に基づいて Switch と Case を評価し、使用する *DefaultOption を決定します。 リゾルバー アルゴリズムは、最も優先度の高いパラメーター (つまり、最小の序数) からパラメーターの設定を決定するため、評価対象のパラメーターの優先度よりも優先順位が低いパラメーターの設定は不明になります。 *DefaultOption ディレクティブを囲む Switch コンストラクトでは、*DefaultOption を使用して既定値が定義されているパラメーターよりも優先順位が高い (つまり、序数が小さい) パラメーターが使用されていることを確認する必要があります。 この規則に従わないと、パーサー関数は失敗します。 この難しさのため、可能な限り Switch および Case コンストラクトに *DefaultOption を挿入しないようにする必要があります。

ResolveConstraint() パーサー インターフェイス関数を呼び出して、制約違反の構成を明示的にチェックし、存在する場合は競合を解決できます。 新しい構成が呼び出し元に返されます。 呼び出し元は、構成が受け入れ可能かどうかを調べるか、構成を使用してスナップショットを取得できます。 スナップショットは、作成時に指定された構成で制約されるパラメーター設定を示します。 この情報は、ユーザー インターフェイスを作成するクライアントに役立つ場合があります。