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

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/