variant list

A list containing variant descriptions, which can be bound to a transparently negotiable resource.

変種一覧

透過折衝可能資源と束縛することができる、 変種記述を含む一覧。

As a general rule, variant lists should be short: it is expected that a typical transparently negotiable resource will have 2 to 10 variants, depending on its purpose. Variant lists should be short for a number of reasons:

一般的な規則として、変種目録は短くあるべきです。 典型的な透過折衝可能資源は、その目的により、 2〜10個の変種を持つことが想定されています。 変種目録はいくつかの理由により短くあるべきです。

• 1. The user must be able to pick a variant by hand to correct a bad automatic choice, and this is more difficult with a long variant list.
• 2. A large number of variants will decrease the efficiency of internet proxy caches.
• 3. Long variant lists will make some transparently negotiated responses longer.

• 利用者は悪い自動選択を正すために変種を手動で選ぶことができなければなりませんが、 これは長い変種目録だとより難しくなります。
• 変種が沢山あるとインターネット串キャッシュの効率が低減します。
• 長い変種目録のせいで透過折衝応答が長くなってしまいます。

In general, it is not desirable to create a transparently negotiable resource with hundreds of variants in order to fine-tune the graphical presentation of a resource. Any graphical fine-tuning should be done, as much as possible, by using constructs which act at the user agent side, for example

通常、資源の図形的表現をよく調整するために数百に及ぶ変種のある透過折衝可能資源を作成するのは望ましからぬことです。 図形的表現をよく調整するのはできる限り利用者エージェント側で動作する構造を使って、 例えば

      <center><img src=titlebanner.gif width=100%
      alt="MegaBozo Corp"></center>

のようにするべきです。

In order to promote user agent side fine tuning, which is more scalable than fine tuning over the network, user agents which implement a scripting language for content rendering are encouraged to make the availability of this language visible for transparent content negotiation, and to allow rendering scripts to access the capabilities and preferences data used for content negotiation, as far as privacy considerations permit this.

ネットワーク上での調整よりも細かに設定できる利用者エージェント側での調整を推進するために、 内容のレンダリングのためのスクリプト言語を実装している利用者エージェントは、 この言語の利用可能性を透過内容折衝から可視とし、 レンダリング・スクリプトがプライバシーを考慮して許せる範囲内において内容折衝に使う能力・希望データに接触可能とすることを推奨します。