IETF media feature registration WG Graham Klyne
Internet draft Content Technologies/5GM
29 July 1999
Expires: January 2000
W3C Composite Capability/Preference Profiles
<draft-ietf-conneg-W3C-ccpp-02.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as ``work in
progress''.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) 1999, The Internet Society
Abstract
This document suggests some possible areas for extending the IETF
'conneg' working group's capability description framework,
described in [2,3,4]. The suggested areas for extension have been
motivated by WWW Consortium (W3C) work on Composite
Capability/Preference Profiles (CCPP) [5] that parallels some
aspects of the IETF 'conneg' work.
This is presented as a discussion document, with a view to maybe
integrating some of these ideas into ongoing 'conneg' work, and to
indicate some areas for ongoing collaboration between the IETF and
W3C in the area of content description.
Klyne [Page 1]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
Table of contents
1. Introduction.............................................2
1.1 Structure of this document ...........................3
1.2 Discussion of this document ..........................3
2. Tag-independent content negotiation......................3
2.1 WWW resource transfer scenario .......................4
2.2 Conclusions ..........................................4
2.3 Consequences .........................................5
3. Assumed feature values...................................5
3.1 Unifying "required" and "default" values .............6
3.2 Message transmission model ...........................7
3.3. Problem summary .....................................8
3.4 Proposed extension to 'conneg' framework .............9
3.4.1 Assumed values construct.........................9
3.4.2 End of chain indicator...........................10
3.4.3 Extended form of conjunction.....................10
3.5 Additional reduction rules ...........................10
3.6 Extended canonicalization rules ......................11
3.7 Examples .............................................12
3.7.1 The "font" problem...............................12
3.7.2 Resolution dependent font........................14
3.7.3 Combining default values.........................14
4. XML representation of capability descriptions............16
5. Mapping between RDF and media features...................17
5.1 An alternative RDF representation ....................20
6. Conclusions..............................................21
7. Security considerations..................................21
8. Full copyright statement.................................22
9. Acknowledgements.........................................22
10. References..............................................22
11. Author's address........................................24
Appendix A. Amendment history ............................24
1. Introduction
This document suggests some possible areas for extending the IETF
'conneg' working group's capability description framework,
described in [2,3,4]. The suggested areas for extension have been
motivated by WWW Consortium (W3C) work on Composite
Capability/Preference Profiles (CCPP) [5] that parallels some
aspects of IETF 'conneg' work.
This is presented as a discussion document, with a view to maybe
integrating some of these ideas into ongoing 'conneg' work, and to
indicate some areas for ongoing collaboration between the IETF and
W3C in the area of content description.
Klyne [Page 2]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
1.1 Structure of this document
The main part of this draft addresses the following main areas:
Section 2 discusses tag-independent negotiation procedures, one of
the goals of the 'conneg' work, with particular reference to WWW
operations
Section 3 suggests a framework for describing "assumed" feature
values.
Section 4 explores an approach to using XML to carry capability
information structured according to the 'conneg' framework.
Section 5 suggests an approach to mapping between RDF [6] and
'conneg' media feature registrations and representations.
[Author's commentary and meta-discussion about the ideas
expressed in this memo is included in paragraphs that are
indented and enclosed in square brackets, like this.]
1.2 Discussion of this document
Discussion of this document should take place on the content
negotiation and media feature registration mailing list hosted by
the Internet Mail Consortium (IMC):
Please send comments regarding this document to:
ietf-medfree@imc.org
To subscribe to this list, send a message with the body 'subscribe'
to "ietf-medfree-request@imc.org".
To see what has gone on before you subscribed, please see the
mailing list archive at:
http://www.imc.org/ietf-medfree/
2. Tag-independent content negotiation
One can imagine two extremes of content negotiation procedure:
o One in which the decisions about whether the features in a data
resource match some set of capabilities are made in full
knowledge of the exact meaning of every feature and capability.
o The other, in which the matching decision is made without any
knowledge of the particular features concerned.
Klyne [Page 3]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
A practical procedure is likely to lie somewhere between these
extremes. Here, we argue that a procedure that minimizes the
required knowledge of particular feature tags is likely to be more
useful than one which depends heavily upon such knowledge.
This approach is described here as "tag-independent negotiation":
negotiation that can proceed without specific knowledge of the tags
used to describe various media features of the participating
entities.
2.1 WWW resource transfer scenario
Consider a WWW transaction scenario that involves content
negotiation:
Resource-1 ->- +--------+ +--------+ ->- Plugin-1
\ | Origin | | | /
Resource-2 ->----| Server |--<--->--| Client |---->- Plugin-2
/ | | | | \
Resource-3 ->- +--------+ +--------+ ->- Plugin-3
In this scenario, the active negotiation takes place between the
origin server and the receiving client.
The resources available to the origin server are possibly passive
data files, with no opportunity for interaction between data
resource and server.
The plugins available to the browser may well be dispatched as
separate programs, with limited opportunity for ongoing interaction
between the plugin and the client. Also, there may be a high
overhead associated with activating a plugin, so it is not
desirable to activate one or more plugins simply to determine
whether a data resource is acceptable to that plugin.
2.2 Conclusions
In an environment like WWW where new and changed features are
deployed on a regular basis, it is clearly not desirable that
detailed knowledge be hard-coded into either the origin server or
the client software. This would rather defeat the idea of
extending functionality through plugins and data resource
abstractions.
Thus, to avoid early obsolescence of both server and client
implementations, we seek a negotiation framework that permits a
data resource to describe itself to the origin server, a plugin to
describe itself to a browser, and allows the server and browser to
conduct negotiations without any further knowledge.
Klyne [Page 4]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
There are doubtless some cases where the degree of negotiating
flexibility indicated here is not essential: "Internet appliances"
and other dedicated devices spring to mind. But even for such
devices, it can be argued that the flexibility of tag-independent
negotiation will simplify their configuration.
2.3 Consequences
Some consequences of the conclusion just outlined are:
o The capability description should be able to describe
dependencies between content features in such a way that they can
be handled by the negotiation protocol.
o The vocabulary used to describe content features should avoid
having multiple ways to describe the same capabilities, as
reconciliation of these would require specific knowledge about
the tags used.
3. Assumed feature values
[This section describes a possible approach to dealing
with "assumed" or "default" feature values. It is
intended to show that incorporation of such ideas into
the 'conneg' framework is possible, and does not claim
that the proposal offered is the best way to proceed, or
even a good way to proceed.]
The W3C CC/PP [5] work embodies a concept that is not currently
supported in the IETF 'conneg' framework [3]; namely the
construction of a set of capability and preference values from a
number of separate sources (e.g. hardware platform defaults,
software platform defaults, user preferences). Also, there is a
desire to have a compact way to represent a small number of
differences from some baseline set of capabilities. What is not
covered by this work, that the IETF 'conneg' work can supply, is a
framework for actually combining the various information sources.
Also, there is an identified capability gap in the IETF 'conneg'
work: the ability to indicate that some particular feature MUST be
supplied by a communicating counter-party. This has been
characterized as the "font problem": how can a sender require that
some particular font is supported by a recipient? Currently the
'conneg' framework operates to effectively ignore a request for an
unknown font, or other unrecognized feature.
Klyne [Page 5]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
3.1 Unifying "required" and "default" values
The two situations we wish to describe are:
(A) "required" values: given two feature set descriptions, the
feature set match is to fail if one of them does not define a
value for a feature tag tested by the other. This is
exemplified by the "fonts" problem: if a data resource uses
some font indicated by the feature tag "Font-obscure", and the
receiver does not explicitly declare an ability to deal with
that font, then we should assume that the feature sets do not
match. As currently defined, the 'conneg' algebraic framework
[3] would allow a feature set match in the absence of an
explicit denial of such support.
(B) "override" and "default" values: given two feature set
descriptions that contain different constraints involving some
feature tag, the constraint from one of the feature sets is to
override the constraint in the other. This is exemplified by
the scenario outlined in the W3 CC/PP draft [5], in which a
hardware manufacturer may supply a default profile for a
device which can then be overridden by local user preferences.
A mechanism that can address both of these requirements is one
which allows a feature set description to indicate "assumed" values
for a given feature.
Case (A):
A data resource requires a given font to be available, and its
feature set description provides "assumed" values for the font
availability that are used only if the recipient does not
itself reference that feature. Thus, if the data resource
indicates:
(Font-obscure=TRUE)
Assume: (Font-obscure=FALSE)
and the recipient does not supply a constraint for 'Font-
obscure', then the assumed value is used to force a feature
set match failure.
Case (B):
A hardware platform capability description consists entirely
of assumed feature values. When combined with user
preferences, these provide values for those features that are
not mentioned in the user preferences.
The ideas here can be extended to deal with combinations of more
than two feature sets.
Klyne [Page 6]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
The assumed value idea breaks a number of assumptions of the
current 'conneg' algebraic model [3], which is based on a
simplified predicate algebra. The sections that follow reconcile
this idea with the existing framework.
3.2 Message transmission model
The following discussion is based on a message transmission model
that assumes multiple feature set constraints. The following
example is from [1], section 3.1:
The life of a data resource may be viewed as:
(C) (T) (F)
[A]-->--[S]-->--[R]-->--[U]
where:
[A] = author of document
(C) = original document content
[S] = message sending system
(T) = transmitted data file (representation of (C))
[R] = receiving system
(F) = formatted (rendered) document data (presentation of (C))
[U] = user or consumer of a document
Here, it is [S] and [R] who exchange negotiation metadata to
decide the form of (T), so these elements are the focus of our
attention.
Negotiation metadata provided by [S] would take account of
available document content (C) (e.g. availability of resource
variants) as well as its own possible ability to offer that
content in variety of formats.
Negotiation metadata provided by [R] would similarly take account
of the needs and preferences of its user [U] as well as its own
capabilities to process and render received data.
This example suggests a generic framework within which negotiation
is conducted: a chain of entities, each of which may impose some
constraint(s) on the message features that can usefully be
transferred:
[.]-->--[E1]-->--[E2]-->-- ... -->--[En]-->--[.]
'[.]' here indicate begin and end of the chain, and '[Ei]' are
entities that may impose feature constraints. If the constraint
predicate associated with '[Ei]' is 'FCi', then the composite
feature constraint for the entire chain is the conjunction of the
individual constraints (using 'conneg' notation [3]):
(& FC1 FC2 ... FCn )
Klyne [Page 7]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
3.3. Problem summary
The 'conneg' algebraic framework depends on combining feature sets
by set intersection (i.e. a logical AND of the predicates that
describe feature sets).
For the purposes of this discussion, all feature set expressions
are reduced to disjunctive normal form: thus, every feature set is
described as a disjunction (union) of one or more subsets, each of
which is described by a conjunction of atomic feature comparisons;
e.g.
(| (& (size=s1) (resolution=r1) (color=c1) )
(& (size=s2) (resolution=r2) (grey=g2) ) )
This is without loss of generality: the combining framework
description [3] shows how more complex expressions can be reduced
to this canonical form.
Now consider the following observations:
(1) all atomic feature comparisons have the form '(ftag relop
fvalue)', where 'ftag' is a feature tag that uniquely
identifies a feature, 'relop' is a comparison operator and
'fvalue' is a particular value associated with the feature
tag.
(2) The conjunction operator is symmetric:
(& A B) == (& B A)
(3) The conjunction operator is associative:
(& A (& B C) ) == (& (& A B) C)
This property is important because it means that the feature
sets are not required to be combined in any specific order.
This point is raised in the CC/PP memo [5], and this is a
property that should be preserved.
(4) The assumed value mechanism outlined above is inherently anti-
symmetric. One of the feature sets used takes precedence over
the other:
(Assume: A B) != (Assume: B A)
(5) The assumed value mechanism, by its very nature, is sensitive
to the particular feature tags used.
Klyne [Page 8]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
(6) Assumed values should be used only when an explicit constraint
for a feature tag cannot be found. For example, if a data
resource has the requirement:
(Font-obscure=TRUE)
and also indicates an assumed value:
Assume: (Font-obscure=FALSE)
The assumed value must be ignored if the recipient asserts:
(Font-obscure=TRUE)
This requirement is captured without imposing an order of
evaluation on the feature set matching process (because such
imposition is considered to make the entire process more
complex and error-prone).
(7) A feature set constraint must be reduced to the predicate form
currently defined by the 'conneg' framework [3] (i.e. all
default values must be eliminated) before a feature collection
(i.e. some specific feature values) can be tested with it.
3.4 Proposed extension to 'conneg' framework
Two extensions to the 'conneg' algebraic framework are proposed:
(a) a "assumed values" construct
(b) an "end-of-chain" indicator
and revision of the conjunction '(&...)' and other processing rules
to take account of these new constructs.
3.4.1 Assumed values construct
This is expressed as:
(+ FC )
where 'FC' is a list of one or more feature constraint expressions.
For an expression in the canonical disjunctive normal form, each is
an atomic feature value constraint (i.e. contains a single feature
comparison).
Klyne [Page 9]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
3.4.2 End of chain indicator
This is expressed as:
(.)
3.4.3 Extended form of conjunction
The canonical form of a conjunction is extended to allow:
(& ... (+ FL) FC (+ FR) ... )
That is, it contains separate, optional assumed value constructs to
the left- and right- of any expression in the conjunction.
Referring to the message transmission chain model, these correspond
to assumed values that are applied "upstream" and "downstream"
along the chain. For example, when feature sets along a chain are
combined:
(& FC1 (& (+ FL2) FC2 (+FR2) ) FC3 )
the 'FL2' assumed values applied to 'FC1', and values 'FR2' are
applied to 'FC3'.
Assumed value constructs can appear anywhere in a conjunction, and
the additional rules below indicate how to process these into the
canonical form.
The '(.)' construct can appear at the left or right hand end of a
conjunction:
(& (.) FC (.) )
It may not appear anywhere else in a conjunction. Additional
processing rules (below) show how these can be used to eliminate
assumed value constructs from a conjunction, thus reducing it to a
simple predicate form.
3.5 Additional reduction rules
The aim of these rules is to allow assumed values to propagate
along the message transfer chain until either (a) it is determined
they are redundant, or (b) the assumed values are used as actual
feature constraints which can be evaluated in the normal way.
The following rules assume that all feature constraints are atomic;
i.e. they refer to a single feature tag. The next section contains
rules for canonicalization of complex predicates to a form with
just atomic feature constraints.
Klyne [Page 10]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
Note that if there are any assumed value constructs present in a
conjunction, re-ordering of the component constraints is allowed
only according to reordering rule below.
(a) Re-ordering of assumed value constraints:
(& ... (+FC1) FC2 ... ) ---> (& ... FC2 (+FC1) ... )
(& ... FC1 (+FC2) ... ) ---> (& ... (+FC2) FC1 ... )
(& ... (+FC1) (+FC2) ... ) ---> (& ... (+FC2) (+FC1) ... )
ONLY IF: FC1 and FC2 reference different feature tags.
(b) Assumed value elimination:
(& ... FC1 (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... )
ONLY IF: FC1, FC2 and FC3 reference the same feature tag,
Two extended forms of this rule allow multiple assumed values
to be eliminated:
(& ... FC1 ... (+FC2) FC3 ... ) ---> (& ... FC1 FC3 ... )
(& ... FC1 (+FC2) ... FC3 ... ) ---> (& ... FC1 FC3 ... )
ONLY IF: FC1, FC2 and FC3 reference the same feature tag,
(c) Default resolution:
(& (.) (+FC1) ... ) ---> (& (.) FC1 ... )
(& ... (+FC1) (.) ) ---> (& ... FC1 (.) )
ONLY IF: the conjunction does not contain any non-assumed
constraint referencing the same feature tag.
3.6 Extended canonicalization rules
The above reduction rules assume a canonical form of predicate
expressions. The canonicalization rules described for the 'conneg'
framework [3] must be extended to handle assumed value constructs.
The main goal of these additional rules is to push assumed values
"down" in the expression so that they are contained within all
disjunctions and conjunctions, and themselves contain only atomic
feature constraints.
(a) Separate default constructs:
(+ FC1 FC2 ... ) ---> (+FC1) (+FC2) ...
Following repeated application of this rule, all default
constructs contain just one feature predicate expression
(conjunction, disjunction or atomic).
(b) Move assumed value into conjunction:
(+ (& FC1 FC2 ... ) ) ---> (& (+FC1) (+FC2) ... )
Klyne [Page 11]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
(c) Move assumed value into disjunction:
(+ (| FC1 FC2 ... ) ) ---> (| (+FC1) (+FC2) ... )
(d) Flatten assumed value nests:
(+ ... (+FC1) ... ) ---> (+ ... FC1 ... )
3.7 Examples
Expressions in the following examples assume left is "upstream" in
the message flow.
3.7.1 The "font" problem
Sender/data resource description:
(& (Font-1=TRUE) (Font-2=TRUE)
(+ (Font-1=FALSE) (Font-2=FALSE) ) )
Recipient description:
(& (Font-1=TRUE) (Font-3=TRUE) )
Combine these to obtain the full transmission path description
(recall that feature sets are matched by combining them with
'(&...)', and left is upstream in the transmission path):
(& (.)
(& (Font-1=TRUE) (Font-2=TRUE) // Sender..
(+ (Font-1=FALSE) (Font-2=FALSE) ) )
(& (Font-1=TRUE) (Font-3=TRUE) ) // Receiver..
(.) )
What follows is a sequence of rewriting rule applications that show
how this expression is processed to eliminate the (+...) constructs
and, in the process, the receiver's lack of support for 'Font-2'
causes the feature set match to fail.
--> [expand (+...)]
(& (.)
(& (Font-1=TRUE) (Font-2=TRUE)
(+ (Font-1=FALSE) ) (+ (Font-2=FALSE) ) )
(& (Font-1-TRUE) (Font-2=TRUE) (Font-4=TRUE) )
(.) )
Klyne [Page 12]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
--> [flatten (&...(&...)...)]
(& (.)
(Font-1=TRUE) (Font-2=TRUE)
(+ (Font-1=FALSE) ) (+ (Font-2=FALSE) )
(Font-1-TRUE) (Font-2=TRUE) (Font-4=TRUE) )
(.) )
--> [collect features, being careful to preserve ordering of
constraints with the same feature tag]:
(& (.)
(Font-1=TRUE) (+ (Font-1=FALSE) ) (Font-1=TRUE)
(Font-2=TRUE) (+ (Font-2=FALSE) )
(Font-3=TRUE) )
(.) )
--> [eliminate un-needed default]
(& (.)
(Font-1=TRUE) (Font-1=TRUE)
(Font-2=TRUE) (+ (Font-2=FALSE) )
(Font-3=TRUE) )
(.) )
--> [Resolve non-eliminated default: move to end, then use (+...)
(.) rewriting rule]
(& (.)
(Font-1=TRUE) (Font-1=TRUE)
(Font-2=TRUE) (Font-2=FALSE)
(Font-3=TRUE) )
(.) )
--> [Combine (&...) with same tag:
(& (.)
(Font-1=TRUE)
(FALSE)
(Font-3=TRUE)
(.) )
Which leaves a conjunction containing FALSE, indicating that there
is no feature set matching all the capability constraints.
Note that the receiver's (Font-3=TRUE) was not eliminated because
it did not use the (+...) mechanism to say, in effect, that the
sender must use it.
Klyne [Page 13]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
3.7.2 Resolution dependent font
A slightly more complex example might be:
Sender/data resource description:
(| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) )
(& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) )
This would match the recipient capabilities:
(& (dpi=100) (Font-simple=TRUE) )
or
(& (dpi=300) (Font-simple=TRUE) (Font-fancy=TRUE) )
But it would not match the recipient capability:
(& (dpi=100) (Font-fancy=TRUE) )
3.7.3 Combining default values
Finally, note there is a possibility to use nested '(& ... (.) )'
constructs for defaults which are restricted to a particular entity
in the transmission chain, for example (which is the type of
scenario discussed in the CC/PP draft):
(& <sender>
(& <system values> (+ <system values> )
<local values> (.) ) ... )
Using the "indirect references" example from the CC/PP memo [5], we
could construct a framework like this:
(& (& (Hardware-defaults) (+ (Hardware-defaults) )
(Hardware-platform) (.) )
(& (Software-defaults) (+ (Software-defaults) )
(Software-platform) (.) )
(EpocEmail)
(EpocCalendar)
(UserPreferences)
(.) )
Klyne [Page 14]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
where:
(Hardware-defaults) :-
(& (Vendor="Nokia")
(Model="2160")
(Type="PDA")
(ScreenSize="800x600x24")
(CPU="PPC")
(Keyboard="Yes")
(Speaker="Yes")
(Memory="16Mb) )
(Hardware-platform) :-
(Memory="32Mb")
(Software-defaults) :-
(& (OS="EPOC1.0")
(HTMLVersion="4.0")
(JavaScriptVersion="4.0")
(WAPVersion="1.0")
(WMLScriptVersion="1.0") )
(Software-platform) :-
(& (Sound="Off")
(Images="Off") )
(EpocEmail) :-
(& (Version="EpocEmail1.0")
(HTMLVersion="4.0") )
(EpocCalendar) :-
(& (Version="EpocCalendar1.0")
(HTMLVersion="4.0") )
end
The repetition of '(Hardware-defaults)' and '(Software-defaults)'
is needed to force application of the default value through
reduction rule 2.5(b), "Assumed value elimination". This is,
however, a little clumsy and suggests introduction of a new
construct and reduction rule.
The new construct, a default end of chain indicator, is expressed
as:
(*)
and its purpose is to force elimination of any unused default
value, using the following rule.
Klyne [Page 15]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
Default value elimination:
(& (*) ... (+FC1) FC2 ... ) ---> (& (*) ... FC2 ... )
ONLY IF: FC1 and FC2 reference the same feature tag.
Thus, the above feature set expression could be re-written as:
(& (& (*) (+ (Hardware-defaults) ) (Hardware-platform) (.) )
(& (*) (+ (Software-defaults) ) (Software-platform) (.) )
(EpocEmail)
(EpocCalendar)
(UserPreferences)
(.) )
where
(etc.)
4. XML representation of capability descriptions
The 'conneg' feature set description framework is well-suited to
being expressed in XML. The previously given example:
(| (& (dpi>=100) (Font-simple=TRUE) (+ (Font-simple=FALSE) ) )
(& (dpi>=300) (Font-fancy=TRUE) (+ (Font-fancy=FALSE) ) ) )
might be represented (in conjunction with an appropriate XML tag
definitions) using something like the following XML:
<or>
<and>
<GE dpi 100 />
<EQ Font-simple TRUE />
<ASSUME>
<EQ Font-simple FALSE />
</ASSUME>
</and>
<and>
<GE dpi 300 />
<EQ Font-fancy TRUE />
<ASSUME>
<EQ Font-fancy FALSE />
</ASSUME>
</and>
</or>
[I am not expert in XML, and the above is almost
certainly flawed. But I do believe that it is possible
to use XML broadly in this way, and would welcome further
comment from any XML cognoscenti.]
Klyne [Page 16]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
5. Mapping between RDF and media features
The following extract is from the RDF Model and Syntax
specification:
"This document introduces a model for representing RDF metadata
as well as a syntax for encoding and transporting this metadata
in a manner that maximizes the interoperability of independently
developed web servers and clients. The syntax presented here
uses the Extensible Markup Language [XML]: one of the goals of
RDF is to make it possible to specify semantics for data based on
XML in a standardized, interoperable manner. [...] It is also
important to understand that this XML syntax is only one possible
syntax for RDF, and that alternate ways to represent the same RDF
data model may emerge."
It is interesting to note that the 'conneg' feature expression
framework shares with the RDF framework this clear intent to
separate the data model from its representative syntax.
In this section, the RDF data model is explored and related to the
'conneg' feature registration namespace. The RDF data model is
very rich compared with that used by 'conneg', so should easily be
capable of representing the concepts used.
IETF 'conneg' deals with the following value-sets:
Feature-tag ::= Token
Feature-value ::= Integer
| Rational
| Boolean
| Token
| String
Feature-collection ::= MAP OF Feature-tag TO Feature-value
Feature-set ::= SET OF Feature-collection
(A MAP is a mapping from some domain to some range, which
associates exactly one range value with each domain value.)
Further, a "Feature-set" is described by a collection of feature
value assertions:
Feature-assertion ::= ( "&", SEQUENCE OF Feature-assertion )
| ( "|", SEQUENCE OF Feature-assertion )
| ( "!", Feature-assertion )
| Atomic-assertion
Atomic-assertion ::= ( Relation, Feature-tag, Feature-value )
Relation ::= "EQ" | "GE" | "LE"
Klyne [Page 17]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
A "Feature-collection" can be represented directly as an RDF
resource, where each feature tag/value pair is an RDF property name
and string value.
A "Feature-set" does not have such an obvious RDF representation.
However, the characterization of RDF as having "predicates" that
associate some "object value" with a "resource" suggests a
representation. Atomic feature value assertions are also
predicates that relate a feature tag with a value.
Thus, to fit the RDF model, we can model a feature as an RDF
"resource", with a tag and one or more value assertions. The
following example models a simple description of a VGA display,
which using 'conneg' notation would be:
(& (pix-x<=640) (pix-y<=480) (color<=256) )
This display might be described by the following RDF:
<rdf:RDF>
<rdf:Description ID="VGA display">
<conneg:Feature-assertion>
<conneg:Feature>
<conneg:Feature-tag="pix-x"/>
<conneg:LE="640"/>
</conneg:Feature>
<conneg:Feature>
<conneg:Feature-tag="pix-y"/>
<conneg:LE="480"/>
</conneg:Feature>
<conneg:Feature>
<conneg:Feature-tag="color"/>
<conneg:LE="256"/>
</conneg:Feature>
</conneg:Feature-assertion>
</rdf:Description>
</rdf:RDF>
In this example, the multiple feature values within a "Feature-
assertion" are taken to be implicitly ANDed together. Other
representations are possible. All 'conneg'-related tags are
assumed to be defined in a 'conneg' namespace.
Klyne [Page 18]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
To take a slightly more complex 'conneg' example:
(| (& (pix-x<=800) (pix-y<=600) (color<=256) )
(& (pix-x<=640) (pix-y<=480) (color<=65536) ) )
This might be represented as:
<rdf:RDF>
<rdf:Description ID="VGA display">
<conneg:Feature-assertion>
<conneg:OR>
<rdf:Description ID="Mode-1">
<conneg:Feature-assertion>
<conneg:Feature>
<conneg:Feature-tag="pix-x"/>
<conneg:LE="800"/>
</conneg:Feature>
<conneg:Feature>
<conneg:Feature-tag="pix-y"/>
<conneg:LE="600"/>
</conneg:Feature>
<conneg:Feature>
<conneg:Feature-tag="color"/>
<conneg:LE="256"/>
</conneg:Feature>
</conneg:Feature-assertion>
</rdf:Description>
<rdf:Description ID="Mode-1">
<conneg:Feature-assertion>
<conneg:Feature>
<conneg:Feature-tag="pix-x"/>
<conneg:LE="640"/>
</conneg:Feature>
<conneg:Feature>
<conneg:Feature-tag="pix-y"/>
<conneg:LE="480"/>
</conneg:Feature>
<conneg:Feature>
<conneg:Feature-tag="color"/>
<conneg:LE="65536"/>
</conneg:Feature>
</conneg:Feature-assertion>
</rdf:Description>
</conneg:OR>
</conneg:Feature-assertion>
</rdf:Description>
</rdf:RDF>
[I am not expert in RDF, and fully expect there are ways
in which the above might to improved. At this stage, the
Klyne [Page 19]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
key ideas I wish to test are: (a) that feature
collections can be modelled directly as RDF resource
descriptions, (b) that feature sets must be modelled as
resources in their own right, and (c) that atomic value
assertions should use the RDF "predicate" form to
indicate the kind of constraint that is being applied.]
5.1 An alternative RDF representation
[This is an alternative, and more complete, RDF
representation suggested by Franklin Reynolds of Nokia;
this takes an approach of encoding all the CONNEG-related
information as XML element data, rather than using
element names and parameters to capture some of the
structure.]
It is worth noting that XML/RDF is not really intended to be
written or read by humans. It is intended as a machine readable
format for metadata. One could imagine an CONNEG algebra to
XML/RDF compiler.
An XML/RDF parser has been published by W3C [9], and has been used
to test some ideas for representing CONNEG expressions in RDF.
XML/RDF provides a rich knowledge representation framework, but it
does *not* currently support numeric data types, numeric relations
or a full complement of logical relations. One approach is to
provide a CONNEG vocabulary that defines terms for those relations.
Consider the following example CONNEG feature list:
(& (pix-x<=640)
(pix-y<=480)
(color<=256) )
A reasonable XML/RDF translation is:
<?xml version="1.0"?>
<RDF xmlns="http://w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:rdf="http://w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:PRF="http://www.w3C.org/TR/WD-profile-vocabulary#"
xmlns:conneg="http://www.ietf.org/mumble/">
<Description ID="VGA display">
<conneg:feature-description rdf:parseType="Resource">
<conneg:conjunction>AND</conneg:conjunction>
<conneg:feature rdf:parseType="Resource">
<PRF:pix-x>640</PRF:pix-x>
Klyne [Page 20]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
<conneg:relation>LE</conneg:relation>
</conneg:feature>
<conneg:feature rdf:parseType="Resource">
<PRF:pix-y>480</PRF:pix-y>
<conneg:relation>LE</conneg:relation>
</conneg:feature>
<conneg:feature rdf:parseType="Resource">
<PRF:color>256</PRF:color>
<conneg:relation>LE</conneg:relation>
</conneg:feature>
</conneg:feature-description>
</Description>
</RDF>
This encoding has some nice properties:
o It separates the CONNEG vocabulary that defines relations from
the feature vocabulary. This is important because support for
multiple feature vocabularies is required.
o "feature-description" and "feature" statements nest in a
relatively natural and human readable manner.
o The W3C parser finds this version acceptable.
6. Conclusions
One of the goals of these proposals is to allow the 'conneg' work
to integrate effectively with ongoing work that is being undertaken
by W3C.
Some constructs and handling rules have been suggested that I
believe capture the required concepts embodied in the W3C work, and
provide a way to manipulate them consistently within the 'conneg'
framework.
7. Security considerations
In general, these proposals are not believed to raise any security
considerations not already inherent in the 'conneg', 'RDF' or
'CC/PP' work.
One area can be seen where further consideration of security
concerns might be required. The use of URLs, per CC/PP, to locate
'conneg' feature set descriptions might open up some exposure to
privacy or denial of service attacks on the referenced description.
Klyne [Page 21]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
8. Full copyright statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. Acknowledgements
The complete, tested example of RDF representation for 'conneg'
feature expressions (section 5.1), along with many other useful
thoughts, was provided by Franklin Reynolds of Nokia.
10. References
[1] "Requirements for protocol-independent content negotiation"
G. Klyne, Integralis Ltd.
Internet draft: <draft-ietf-conneg-requirements-00.txt>
Work in progress, March 1998.
[[[Last-called for informational RFC: replace RFC reference]]]
[2] RFC 2506, "Media Feature Tag Registration Procedure"
Koen Holtman, TUE
Andrew Mutz, Hewlett-Packard
Ted Hardie, NASA
March 1999.
Klyne [Page 22]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
[3] RFC 2533, "A syntax for describing media feature sets"
Graham Klyne, 5GM/Content Technologies
March 1999.
[4] RFC 2534, "Media Features for Display, Print, and Fax"
Larry Masinter, Xerox PARC
Koen Holtman, TUE
Andrew Mutz, Hewlett-Packard
Dan Wing, Cisco Systems
March 1999.
[5] "Composite Capability/Preference Profiles (CC/PP):
A user side framework for content negotiation"
Franklin Reynolds, Nokia Research
W3C Note <http://www.w3.org/TR/NOTE-CCPP/>
November 1998
[6] "Resource Description Framework (RDF) Model and Syntax
Specification"
Ora Lassila, Nokia Research Centre
Ralph R Swick, World Wide Web Consortium
W3C working draft: <http://www.w3.org/TR/WD-rdf-syntax>
October 1998
[7] "Resource Description Framework (RDF) Schema Specification"
Dan Brickley, University of Bristol
R. V. Guha, Netscape
Andrew Layman, Microsoft
W3C working draft: <http://www.w3.org/TR/WD-rdf-syntax>
August 1998.
[8] "Extensible Markup Language (XML) 1.0"
Tim Bray, Textuality and Netscape
Jean Paoli, Microsoft
C. M. Sperberg-McQueen, University of Illinois at Chicago
W3C Recommendation: <http://www.w3.org/TR/REC-xml>
February 1998.
[9] XML/RDF parser
<http://jigsaw.w3.org:8000/description>
Klyne [Page 23]
Internet draft 29 July 1999
W3C Composite Capability/Preference Profiles
11. Author's address
Graham Klyne
Content Technologies Ltd. 5th Generation Messaging Ltd.
Forum 1 5 Watlington Street
Station Road Nettlebed
Theale Henley-on-Thames
Reading, RG7 4RA RG9 5AB
United Kingdom United Kingdom.
Telephone: +44 118 930 1300 +44 1491 641 641
Facsimile: +44 118 930 1301 +44 1491 641 611
E-mail: GK@ACM.ORG
Appendix A. Amendment history
[[[Please remove this section on final publication]]]
00a 19-Oct-1998
Document initially created.
00b 20-Oct-1998
Added sections on tag-independent negotiation, XML syntax
and RDF mapping.
00c 31-Oct-1998
Fixed up section numbers.
01a 15-Dec-1998
Minor editorial revisions for re-issue. Updated CC/PP
reference to published W3C Note.
02a 29-Jul-1999
Add in alternative RDF example. Add reference to W3C RDF
parser. Update references. Update copyright year.
Update introductory boilerplate. Add disclaimer
regarding the suitability of proposals in section 3.
Used indented [...] paragraphs for author's commentary on
the ideas in this memo. Various minor corrections.
Klyne [Page 24]
