Subject: Re: Framework for capabilities and user preferences

From: Graham Klyne <[email-masked]>
Date: Fri, 09 Oct 1998 15:06:24 +0100

Johan,

Regarding the W3C CC/PP framework document you sent.  I'd like to second
Ted's thanks for bringing this to our attention.

I've taken a first pass at this document;  my comments below may be
off-base due to my limited knowledge of XML and RDF.  I have pulled the
referenced RDF documents to review when I get a chance.

Bearing in mind the above disclaimer, some instant thoughts I have are:

1. It's not accurate to characterize our work as an extension of MIME.  The
conneg framework stands independently of MIME (though I would expect it to
be used in conjunction with MIME).

(BTW: the CC/PP document made mention of tokenized XML;  can you supply a
reference for this please?)

2. I think that the CC/PP work and ours is both complementary and overlapping.

3. I have no problem at all with the idea that XML might provide an
alternate syntax for capability statements.  To my mind, syntax and
semantics are separate issues.  The RDF framework *seems* to be similar to
the conneg -reg- framework.  Indeed, I expect that registered feature tags
could easily be incorporated into RDF.

4. I have concerns that CC/PP might be developing an alternate,
incompatible semantics to that in draft-ietf-conneg-feature-syntax-xx.

5. We have made a clear distinction between "feature collections" and
"feature sets", for which I find no indication in the CC/PP work.  A table
of RDF statements seems to correspond to our idea of a feature collection,
with the RDF statements (and namespaces) corresponding to our idea of
feature tags and values.

The 'feature set' concept is important because it captures a range of
possible values and possible combinations of values, which (for example)
our work in describing fax device capabilities has indicated to be very
important.  Without the concept of feature sets, the whole idea of content
*negotiation* would seem to have very little value.

I also have the impression that your framework leaves the semantics of
matching capability descriptions to the application:  it provides a way to
describe some features, but no way to determine whether or not they match.
E.g. which variant of a Web resource (described by some feature assertion)
is appropriate to send to some recipient (also described by some feature
assertion)?

The approach in draft-ietf-conneg-feature-syntax-xx is to provide
descriptions which (as far as possible) are matchable in a protocol- and
application- independent fashion.

On the other hand, I think our basic "feature collection" description is
not as rich as that afforded by RDF.

6. I think the 'conneg' work needs some concept of asymmetric combination
of feature sets that captures the ideas of precedence mentioned in the
CC/PP draft, and the idea of "these features and no others" that we have
noted.  I think it *may* be that a common algebraic framework can handle
both.  As yet, I have not had time to really think hard about this problem,
but your ideas will be some useful aditional input.

(We have previously characterized this issue as "how does one describe a
system as being capable of supporting some given set of fonts, and no
others."  Currently, the 'conneg' framework does not capture this idea.
But I'm still thinking at it.)

7. There is a very useful idea of "delta-features" (my ugly phrase) that is
raised in the CC/PP draft.  I think it is semantically equivalent to
precedence, but probably a useful idea.

8. The CC/PP approach seems to be determined to solve the feature set
publication problem that we discussed and shied away from, through the use
of URIs to identify feature sets, with the explicit intention that they are
retrievable.  (We in 'conneg' discussed the idea that a URI feature tag
could reference a machine-retrievable description of that feature, but felt
that this was too much to impose on all implementations of the basic
framework we are developing.  The idea isn't ruled out entirely, it's just
not part of our current work plan.)

In summary, I think we should work together if possible and pool ideas.  If
we don't, I think there is a real probability that we'll end up with
incompatible frameworks.  I'd really appreciate a chance to meet up with
someone who is working on the CC/PP framework so that:
(a) I can gain a deeper understanding of the XML and RDF issues, and
(b) impart an understanding of the feature dependencies that we are trying
to capture.

In my first pass of the CC/PP document, a couple of questions did arise:

(1) It was not clear to me how the "table of tables" data model was used.
I could see the use of a single table to describe some set of attributes,
but beyond this I could only see a "set of tables" being used to collect
individual tables from different sources.

(2) In looking at the second example in the paper ("indirect references"),
I could not see how the referencing URI was related to the related profile.
 I assume that the given profile is made accessible at the appropriate URL.

#g

------------
Graham Klyne
([email-masked])

---

From: Graham Klyne <[email-masked]>
Date: Fri, 09 Oct 1998 18:04:10 +0100

Johan,

I have a few slightly more detailed comments from a second reading of the
W3C CC/PP framework document you sent.

My thrust here is still to fully understand where the W3C work and ours
differs, and where we have a common view, with a view to hopefully
establishing a common semantic framework (or at least compatible frameworks).

Also, I have yet to read the RDF and XML namespace documents.

[...]
>2. Introduction 

[...]
>To complete the negotiation some rule is needed for selecting a version of
>the document based on weighing the user's proficiency in
>different languages against the quality of the documents various
translations. 

In disscussions, some of us have adopted a view that the idea of
formulating a universal rule for combining preference indications is
fraught with difficulties and likely to result in apparently inconsistent
observed system behaviour.  Therefore, although numeric values are used for
indicating preferences, they are regarded simply as a ranking mechanism and
arithmetic operations on them are explicitly excluded.

[...]
>Though we hope that
>the use of RDF to encode the metadata describing the content and the
user's >preferences will facilitate the development of
>solutions to these kinds of complex negotiations, the implementation of
>appropriate rules for the negotiation is left to application developers. 

We in 'conneg', too, are following this approach.

[...]
>3. Meta data and profiles 
>
[...]
>It is interesting to note that metadata (capabilities and preferences)
>associated with the device, the software used to access the
>web and the user of the device could originate from different sources
>created at different times.

Your document seems to focus on device, software and user preferences.  The
framework that 'conneg' is pursuing also allows for description of the data
resources, so a unified framework for matching content to recipient can be
provided.

[...]
>4. Composite Capability/Preferences Profiles (CC/PP) 
>
[...]
>From the point of view of any particular network transaction the only
>property or capability information that is important is
>whatever is "current".  The network transaction does not care about the
>differences between defaults or persistent local
>changes, it only cares about the capabilities and preferences that apply
>to the current network transaction.

Effectively, 'conneg' assumes that we *start* with a collection of
"current" capability assertions...

>Because this
>information may originate from multiple sources and because different parts
>of the capability profile may be differentially cached,
>the various components must be explicitly described in the network
>transaction. 

... thus, I think, we have very different concepts of "composition".  The
CC/PP document seems to focus on the idea of composition of information
from different sources describing a given entity.  The conneg work does not
expose this concept.  Though, as indicated in my previous message, I do
believe this may be a very useful concept.

Our "composition" framework is one that captures and expresses combinations
of allowable media features (e.g. 800*600 resolution AND 256 colours, OR
640*480 resolution AND 65000 colours), and combining these as they apply to
different messaging entities (original data resource, sender, recipient,
etc.) to determine a set of features that is compatible all along the
message transfer chain.  This gives rise to the distinction between
"feature collections" and "feature sets" mentioned in my previous message.

I don't believe these approaches are incompatible, but that it is important
to recognize that we are addressing different issues here.

> RDF processing does not implicitly preserve order. Consequently the value
>of a property cannot be changed by simply having
>another statement assigning a different value to a property with the same
>name.  Instead of overriding the previous value of the
>property, you get two properties with the same name and two different
>values. RDF processing does not guarantee
>preservation of declaration order so there is no way to use declaration
>order to define a precedence relation. To get the effect
>of overriding the properties of a platforms defaults, the platform
>attributes are aggragated  via a "description block". This makes
>it possible for an application to define a precedence relation between
>platform defaults and user specified overrides. 

Passing reference is made here to a "description block", but I don't see
this described anywhere.

Also, later in this document, at the end of section 4.2 (see below), it is
asserted that responsibility for applying the precedence is with the
application, implying (to me) that the application provides the precedence
rules.  These two statements seem to me to be inconsistent.

[...]
>4.2 Indirect References 
[...]
>It is up the application to enforce the rule that user
>specified attributes over ride default values. RDF does not provide
>a convenient mechanism for implementing that rule. 

(see comments above)

---

#g

------------
Graham Klyne
([email-masked])