[16] [DFN[[RUBYB[[[特徴集合]]]@en[feature set]]]]は、[[利用者]]や[[利用者エージェント]]の[[能力や好みを表す][能力の記述]][[特徴タグ]]と値の[[集合]]です。

* 仕様書

[REFS[
- [1] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) <http://tools.ietf.org/html/rfc2295#section-6.2>
]REFS]

* 意味

[3] [[利用者エージェント]]の[[特徴集合]]とは、
[[利用者エージェント]]の能力と[[利用者]]の[RUBYB[好み]@en[preference]]を記録した[[データ構造]]です [SRC[>>1]]。

[6] [[特徴集合]]は、[[特徴タグ]]、および[[特徴タグ]]の値0個以上の[[集合]]の組によって構成される[RUBYB[[[記録]]]@en[record]]の[[集合]]です。[[空集合]]かもしれません。 [SRC[>>1]]

[8] 値を持てない[[特徴タグ]]の場合は、値の[[集合]]は[[空集合]]です [SRC[>>1]]。

[9] 値を持てる[[特徴タグ]]の場合は、現在当該[[特徴タグ]]に関連付けられている値の[[集合]]を表します。この[[集合]]にある値が含まれることを、[[特徴タグ]]にある値が[RUBYB[現れる]@en[present]]といいます。 [SRC[>>1]]

[7] [[特徴集合]]にある[[記録]]が含まれる場合、[[利用者エージェント]]がその能力を実装している、
または[[利用者]]がその好みを表明していることを意味します [SRC[>>1]]。

* 構文

[10] [[特徴集合]]は[[データ構造]]であり、情報交換用の構文は用意されていません。

[11] ただし仕様書は次のような表記を採用しています [SRC[>>1]]。
>
[PRE[
      { ( "frames" , { } ) ,
        ( "paper"  , { "A4" , "A5" } )
      }
]PRE]

* 文脈

[4] [[機能集合]]は[[局所異体選択アルゴリズム]]で使用します [SRC[>>1]]。

[5] [[利用者エージェント]]は、[[機能集合]]の一部を[[遠隔異体選択アルゴリズム]]に知らせるべく、
[CODE(HTTP)@en[[[Accept-Features:]]]] [[ヘッダー]]を指定できます [SRC[>>1]]。

* 処理モデル

[12] [[特徴集合]]に未知の[[特徴タグ]]が含まれる場合は、それが含まれないものとして扱う[['''べきです''']] [SRC[>>1]]。

[13] [[利用者エージェント]]は[[要求]]の種類に応じて[[特徴集合]]の内容を変化させても構いませんし、状況によって更新しても構いません [SRC[>>1]]。

[EG[
[14] 例えば[[窓]]の大きさ [SRC[>>1]] は[[利用者]]の操作により変化します。
]EG]

;; [15] この性質を強調するために[RUBYB[[[現在の要求の特徴集合]]]@en[the feature set of the current request]]と言います。

* 歴史

[FIG(quote)[
[FIGCAPTION[
[2] RFC 2295 (HTTP 透過内容折衝) 6.2 Feature sets
]FIGCAPTION]

> The feature set of a user agent is a data structure which records the
capabilities of the user agent and the preferences of the user.

[[利用者エージェント]]の[DFN[特徴集合]]は、
利用者エージェントの能力と利用者の好みを記録するデータ構造です。

> Feature sets are used by local variant selection algorithms (see
appendix 19 for an example).  A user agent can use the Accept-Features header (section 8.2) to make some of the contents of its
feature set known to remote variant selection algorithms.

特徴集合は[[局所変種選択算法]]で使います。
利用者エージェントは特徴集合の内容の幾つかを[[遠隔変種選択算法]]に知らせるために
[CODE(HTTP)[[[Accept-Features]]]] 頭を使っても構いません。

> Structurally, a feature set is a possibly empty set, containing
records of the form
[PRE[
      ( feature tag , set of feature tag values )
]PRE]

> If a record with a feature tag is present in the set, this means that
the user agent implements the corresponding capability, or that the
user has expressed the corresponding preference.

> Each record in a feature set has a, possibly empty, set of tag
values.  For feature tags which cannot have values associated with
it, this set is always empty.  For feature tags which can have zero,
one, or more values associated with it, this set contains those
values currently associated with the tag.  If the set of a feature
tag T has the value V in it, it is said that `the tag T is present
with the value V'.

> This specification does not define a standard notation for feature
sets.  An example of a very small feature set, in a mathematical notation, is
[PRE[
      { ( "frames" , { } ) ,
        ( "paper"  , { "A4" , "A5" } )
      }
]PRE]

> As feature registration is expected to be an ongoing process, it is
generally not possible for a user agent to know the meaning of all
feature tags it can possibly encounter in a variant description.  A
user agent SHOULD treat all features tags unknown to it as absent from its feature set.

> A user agent may change the contents of its feature set depending on
the type of request, and may also update it to reflect changing
conditions, for example a change in the window size.  Therefore, when
considering feature negotiation, one usually talks about `the feature set of the current request'.
]FIG]
