📄 rfc2533.txt
字号:
the predicates represented by those filters.
(| f1 f2 ... fn ) is the logical-OR of the filter values 'f1',
'f2' up to 'fn'. That is, it is satisfied by
any feature collection that satisfies at least
one of the predicates represented by those
filters.
Klyne Standards Track [Page 12]
RFC 2533 A Syntax for Describing Media Feature Sets March 1999
(! f1 ) is the logical negation of the filter value
'f1'. That is, it is satusfied by any feature
collection that does NOT satisfy the predicate
represented by 'f1'.
4.2.2 Feature comparison
A feature comparison is defined by the 'simple' option of the syntax
production for 'item'. There are three basic forms:
(ftag=value) compares the feature named 'ftag' (in some
feature collection that is being tested) with
the supplied 'value', and matches if they are
equal. This can be used with any type of
feaure value (numeric, Boolean, token or
string).
(ftag<=value) compares the numeric feature named 'ftag' with
the supplied 'value', and matches if the
feature is less than or equal to 'value'.
(ftag>=value) compares the numeric feature named 'ftag' with
the supplied 'value', and matches if the
feature is greater than or equal to 'value'.
Less-than and greater-than tests may be performed with feature values
that are not numeric but, in general, they amount to equality tests
as there is no ordering relation on non-numeric values defined by
this specification. Specific applications may define such ordering
relations on specific feature tags, but such definitions are beyond
the scope of (and not required for conformance to) this
specification.
4.2.3 Feature tags
Feature tags conform to the syntax given in "Media Feature Tag
Registration Procedure" [3]. Feature tags used to describe
capabilities should be registered using the procedures described in
that memo. Unregistered feature tags should be allocated in the "URI
tree", as discussed in the media feature registration procedures memo
[3].
If an unrecognized feature tag is encountered in the course of
feature set predicate processing, it should be still be processed as
a legitimate feature tag. The feature set matching rules are
designed to allow new feature tags to be introduced without affecting
the validity of existing capability assertions.
Klyne Standards Track [Page 13]
RFC 2533 A Syntax for Describing Media Feature Sets March 1999
4.2.4 Feature values
A feature may have a number, Boolean, token or string value.
4.2.4.1 Boolean values
A Boolean is simply a token with two predefined values: "TRUE" and
"FALSE". (Upper- or lower- case letters may be used in any
combination.)
4.2.4.2 Numeric values
A numeric value is either a decimal integer, optionally preceded by a
"+" or "-" sign, or rational number.
A rational number is expressed as "n/m", optionally preceded by a "+"
or "-" sign. The "n" and "m" are unsigned decimal integers, and the
value represented by "n/m" is "n" divided by "m". Thus, the
following are all valid representations of the number 1.5:
3/2
+15/10
600/400
Thus, several rational number forms may express the same value. A
canonical form of rational number is obtained by finding the highest
common factor of "n" and "m", and dividing both "n" and "m" by that
value.
A simple integer value may be used anywhere in place of a rational
number. Thus, we have:
+5 is equivalent to +5/1 or +50/10, etc.
-2 is equivalent to -2/1 or -4/2, etc.
Any sign in a rational number must precede the entire number, so the
following are not valid rational numbers:
3/+2, 15/-10 (**NOT VALID**)
4.2.4.3 Token values
A token value is any sequence of letters, digits and '-' characters
that conforms to the syntax for 'token' given above. It is a name
that stands for some (unspecified) value.
Klyne Standards Track [Page 14]
RFC 2533 A Syntax for Describing Media Feature Sets March 1999
4.2.4.4 String values
A string value is any sequence of characters enclosed in double
quotes that conform to the syntax for 'string' given above.
The semantics of string defined by this memo are the same as those
for a token value. But a string allows a far greater variety of
internal formats, and specific applications may choose to interpret
the content in ways that go beyond those given here. Where such
interpretation is possible, the allowed string formats and the
corresponding interpretations should be indicated in the media
feature registration (per RFC 2506 [3]).
4.2.5 Notational conveniences
The 'set' option of the syntax production for 'item' is simply a
shorthand notation for some common situations that can be expressed
using 'simple' constructs. Occurrences of 'set' items can eliminated
by applying the following identities:
T = [ E1, E2, ... En ] --> (| (T=[E1]) (T=[E2]) ... (T=[En]) )
(T=[R1..R2]) --> (& (T>=R1) (T<=R2) )
(T=[E]) --> (T=E)
Examples:
The expression:
( paper-size=[A4,B4] )
can be used to express a capability to print documents on either A4
or B4 sized paper.
The expression:
( width=[4..17/2] )
might be used to express a capability to print documents that are
anywhere between 4 and 8.5 inches wide.
The set construct is designed so that enumerated values and ranges
can be combined in a single expression, e.g.:
( width=[3,4,6..17/2] )
4.3 Feature set definition example
The following is an example of a feature predicate that describes a
number of image size and resolution combinations, presuming the
registration and use of 'Pix-x', 'Pix-y', 'Res-x' and 'Res-y' feature
tags:
(| (& (Pix-x=1024)
Klyne Standards Track [Page 15]
RFC 2533 A Syntax for Describing Media Feature Sets March 1999
(Pix-y=768)
(| (& (Res-x=150) (Res-y=150) )
(& (Res-x=150) (Res-y=300) )
(& (Res-x=300) (Res-y=300) )
(& (Res-x=300) (Res-y=600) )
(& (Res-x=600) (Res-y=600) ) ) )
(& (Pix-x=800)
(Pix-y=600)
(| (& (Res-x=150) (Res-y=150) )
(& (Res-x=150) (Res-y=300) )
(& (Res-x=300) (Res-y=300) )
(& (Res-x=300) (Res-y=600) )
(& (Res-x=600) (Res-y=600) ) ) ) ;q=0.9
(& (Pix-x=640)
(Pix-y=480)
(| (& (Res-x=150) (Res-y=150) )
(& (Res-x=150) (Res-y=300) )
(& (Res-x=300) (Res-y=300) )
(& (Res-x=300) (Res-y=600) )
(& (Res-x=600) (Res-y=600) ) ) ) ;q=0.8 )
5. Matching feature sets
This section presents a procedure for combining feature sets to
determine the common feature collections to which they refer, if
there are any. Making a selection from the possible feature
collections (based on q-values or otherwise) is not covered here.
Matching a feature set to some given feature collection is
essentially very straightforward: the feature set predicate is
simply evaluated for the given feature collection, and the result
(TRUE or FALSE) indicates whether the feature collection matches the
capabilities, and the associated quality value can be used for
selecting among alternative feature collections.
Matching a feature set to some other feature set is less
straightforward. Here, the problem is to determine whether or not
there is at least one feature collection that matches both feature
sets (e.g. is there an overlap between the feature capabilities of a
given file format and the feature capabilities of a given recipient?)
This feature set matching is accomplished by logical manipulation of
the predicate expressions as described in the following sub-sections.
For this procedure to work reliably, the predicates must be reduced
to a canonical form. The canonical form used here is "disjunctive
normal form". A syntax for disjunctive normal form is:
Klyne Standards Track [Page 16]
RFC 2533 A Syntax for Describing Media Feature Sets March 1999
filter = orlist
orlist = "(" "|" andlist ")" / term
andlist = "(" "&" termlist ")" / term
termlist = 1*term
term = "(" "!" simple ")" / simple
where "simple" is as described previously in section 4.1. Thus, the
canonicalized form has at most three levels: an outermost "(|...)"
disjunction of "(&...)" conjunctions of possibly negated feature
value tests.
NOTE: The usual canonical form for predicate expressions is
"clausal form". Procedures for converting general predicate
expressions are given in [5] (section 10.2), [11] (section 2.13)
and [12] (section 5.3.2).
"Clausal form" for a predicate is similar to "conjunctive normal
form" for a proposition, being a conjunction (logical AND) of
disjunctions (logical ORs). The related form used here, better
suited to feature set matching, is "disjunctive normal form",
which is a logical disjunction (OR) of conjunctions (ANDs). In
this form, the aim of feature set matching is to show that at
least one of the disjunctions can be satisfied by some feature
collection.
Is this consideration of canonical forms really required? After
all, the feature predicates are just Boolean expressions, aren't
they? Well, no: a feature predicate is a Boolean expression
containing primitive feature value tests (comparisons),
represented by 'item' in the feature predicate syntax. If these
tests could all be assumed to be independently TRUE or FALSE, then
each could be regarded as an atomic proposition, and the whole
predicate could be dealt with according to the (relatively simple)
rules of Propositional Calculus.
But, in general, the same feature tag may appear in more than one
predicate 'item', so the tests cannot be regarded as independent.
Indeed, interdependence is needed in any meaningful application of
feature set matching, and it is important to capture these
dependencies (e.g. does the set of resolutions that a sender can
supply overlap the set of resolutions that a recipient can
handle?). Thus, we have to deal with elements of the Predicate
Calculus, with some additional rules for algebraic manipulation.
A description of both the Propositional and Predicate calculi can
be found in [12].
Klyne Standards Track [Page 17]
RFC 2533 A Syntax for Describing Media Feature Sets March 1999
We aim to show that these additional rules are more unfamiliar
than complicated. The construction and use of feature predicates
actually avoids some of the complexity of dealing with fully-
generalized Predicate Calculus.
5.1 Feature set matching strategy
The overall strategy for matching feature sets, expanded below, is:
1. Formulate the feature set match hypothesis.
2. Replace "set" expressions with equivalent comparisons.
3. Move logical negations "inwards", so that they are all applied
directly to feature comparisons.
4. Eliminate logical negations, and express all feature comparisons
in terms of just four comparison operators
5. Reduce the hypothesis to canonical disjunctive normal form (a
disjunction of conjunctions).
6. For each of the conjunctions, attempt to show that it can be
satisfied by some feature collection.
6.1 Separate the feature value tests into independent feature
groups, such that each group contains tests involving just one
feature tag. Thus, no predicate in a feature group contains a
feature tag that also appears in some other group.
6.2 For each feature group, merge the various constraints to a
minimum form. This process either yields a reduced expression
for the allowable range of feature values, or an expression
containing the value FALSE, which is an indication that no
combination of feature values can satisfy the constraints (in
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -