Subject: Re: cardinal q-factors

From: Graham Klyne <[email-masked]>
Date: Mon, 12 Oct 1998 11:22:26 +0100

At 15:13 09/10/98 -0400, Al Gilman wrote:
>Now I can't find it to quote.
>
>I have a memory of Ted saying "we explicitly ruled out using
>q-factors in weighted-factors combining rules."
>
>Did this happen?

The use or arithmetic on q-factors is excluded in the -algebra- draft.
Unfortunately, I note that bit did not make it into the -syntax- draft
(which was intended to be a simplified presentation of -algebra- with
emphasis on the actual syntax.)  The following is an extract from -algebra-
section 5:

  Numeric quality values in the range 0 to 1 (as defined by RFC 2068
  [9], section 3.9) are used to rank feature sets according to
  preference.  Higher values are preferred over lower values, and
  equal values are presumed to be equally preferred.  Beyond this,
  the actual number used has no significance, and should not be used
  as a basis for any arithmetic operation.

>If that it true, it got by me.  I thought that cardinal
>q-factors were available as an extension possibility, i.e that

I don't recall any such consensus -- but I am prepared to be put right on
this.

#g

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

---

From: Al Gilman <[email-masked]>
Date: Mon, 12 Oct 1998 12:52:48 -0400 (EDT)

> I don't recall any such consensus -- but I am prepared to be put right on

1. I don't recall any consensus either way.  And I apologize for
not reading the algebra draft in a more timely manner.  My
reaction is based on preliminary discussions on extensibility
long gone by now.

2. I would, however, suggest that the final sentence including
the clause "and should not be used as a basis for any arithmetic
operation" is unduly restrictive of the possibilities for
beneficial future extension and should be removed from the draft
before it becomes a proposed standard.

In his latest mutterings about the vision of the future Web, Tim
Berners-Lee has been including the concept of "partial
understanding."  I have a conceptual sketch of how this would be
applied to benefit the seamless integration of adaptive
transforms for people with disabilities.  In buzzwords, the
routine way of handling the information would operate by compiled
implementations of weaker superclasses and the alterantive way of
handling the information would operate by interpretive,
downloadable-patch implementations of stronger subclasses.

If you don't leave things like the cardinal semantics of
q-factors open for such subclass strengthening, this strategy
cannot be applied.

I don't think it takes two competing implementations of the
extension to justify the idea that the restriction is improper.

The standard should stick to defining what it defines, and not
try to forbid extension-by-restriction.

The "deal" I thought we had long ago was that nothing in the
initial standard would prevent certain kinds of extensions,
including creating registered subtypes by registering the
operations and/or rules of the subtype and inheriting values and
existing operations and rules from the established canon composed
of the standards and prior registrations.

Al

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 13 Oct 1998 17:32:58 PDT

> of the standards and prior registrations.

A standard can call for implementations to avoid non-standard extensions
in an area JUST SO future standards can define what it means. If we've
come to the conclusion that applying semantics to arithmetic on q-factors
requires further study, it's a good idea to note that such extensions
are not allowed by this version.

I don't see anything inconsistent about saying "and should not be used
as a basis for any arithmetic operation", but you might find it
easier to swallow if the wording were changed from something that
is proscriptive ("don't do this") to descriptive ("if you do this
the results will be unpredictable"). After all, I'm free to do any
arithmetic I want on Q-values in the privacy of my implementation, it's
just that the exercise is futile, since they don't carry those semantics.

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: [email-masked] (Ted Hardie)
Date: Wed, 14 Oct 1998 15:25:08 -0700 (PDT)

I have at different times in the past asked the group to put off
discussion of preferences and q-values while some basic work
got done, and I still believe that progress in this group is more
likely if we do a "build out" approach.  This does not mean I
believe that q-values are essentially evil or that they should
never have any semantics; it does mean that, as chai, I did not believe
we could get a registration document finished if we started
off tackling that issue.

Taking off my blue dot for a moment, I would like to note that
using numbers to express preferences and quality seems to induce
a near-hormonal urge in some people to divide, multiply, add,
subtract, or otherwise manipulate those values.  Experience
with TCN and other systems suggests that many of the values
expressed in q-values are assigned subjectively and that
such manipulations are thus extremely suspect (if the distance
between 7 and 8 is not the same as that between 3 and 4 and
neither is consistent, arithmetical operations on 7, 8, 3, and 4
are likely to be inconsistent at best).

I believe Larry's wording below gets that across as well or
better than prescriptive language would, and I would be
happy with that change, if others agree.
		regards,
			Ted Hardie
			NASA/STX

And Larry Masinter replied:
>-- End of excerpt from Larry Masinter

---

From: Al Gilman <[email-masked]>
Date: Wed, 14 Oct 1998 18:55:05 -0400 (EDT)

> > just that the exercise is futile, since they don't carry those semantics.

I agree that there should be such a warning.

I have one minor wrinkle to ask about.

I am curious what people see as the division of labor between
consensus documents and first-come-first-served registrations in
this regard.

I was trying to lay the groundwork for a protocol to say "I am
going to use q-factors with this quantitative rationale and
significance" in a _registration_ and then proceed to use them
consistently as thus described.

I wanted the incremental semantics to be able to reuse the
established syntax because of the graceful degradation so
obtained.  An implementation recognizing the registration would
get the full value of the q-factor sent.  An implementation only
relying on the standard would not employ this use, but would
still get the correct sense from order comparisons.

So I would have preferred that the warning say "...are likely to
produce unpredictable results unless they have been defined in
advance by a registration."

Could be total pie in the sky.  But where there's a registry, I
can dream.

Al

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 14 Oct 1998 17:31:06 PDT

Al,

> advance by a registration."

"a registration" won't tell you how two features interact.

The problem is that if you're not concerned about the
interaction of one feature with another, then you don't
need to do arithmetic -- you just have a simple comparison.

And if you are concerned about the interaction with one
feature and another, then you can't describe that interaction
in the registration of a single feature.

Larry

---

From: Al Gilman <[email-masked]>
Date: Wed, 14 Oct 1998 21:47:45 -0400 (EDT)

> need to do arithmetic -- you just have a simple comparison.

I am having trouble understanding this.  A scenario I would
imagine is one where there are two possible choices which 
differ in one characteristic.  The q factors are:

	q=		Choice1		Choice2

	Server		0.39		0.3
	User		0.6		0.7

Here if q factors add you pick choice 2, if they multiply, you
pick choice 1 and from the standard you have a hung jury, because
each party to the negotiation has a different preference.

> in the registration of a single feature.

If feature A exist in the standard and feature B is defined
by a later registration, why can't the interaction of A and B
be defined in the registration for B?

Besides, why can't one register just the arithmetic that you plan
to use for q factors associated with selected standard features?

So long as the defined arithmetic doesn't violate the
pre-ordained order semantics, this should be OK.
 
Al

---

From: "Martin J. Duerst" <[email-masked]>
Date: Thu, 15 Oct 1998 10:29:51 +0900

> in the registration of a single feature.

Not exactly true if we (as I think is the intent here) assume
that features are used both for preference and for capability
description. Language negotiation immediately comes to my mind.

If there are two documents,  A with Content-Language: fr;q=0.8
and B with Content-Language: de;q=0.6, and you send something
of the equivalent (don't worry about the syntax, I probably
have it wrong) of Accept-Language: fr,q=0.3.5; de,q=0.5, then
which way to go?

Regards,  Martin.

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 15 Oct 1998 00:56:18 PDT

> have it wrong) of Accept-Language: fr,q=0.3.5; de,q=0.5, then

??? the Q factors apply only to preference, and not to description.
You have two documents, A with content-language: fr. There is
no ";q=0.8" associated with "content-language".

Larry

---

From: "Martin J. Duerst" <[email-masked]>
Date: Thu, 15 Oct 1998 17:11:48 +0900

> no ";q=0.8" associated with "content-language".

Indeed the q factors don't show up in the Content-Language header.
But they may be around on the server.

Regards,   Martin.

---

From: [email-masked] (Koen Holtman)
Date: Thu, 15 Oct 1998 19:24:56 +0200 (MET DST)

>But they may be around on the server.

In the TCN framework these server-side language q factors would end up
in the 'source quality' value of the document.  TCN suggests to use
multiplication to decide where to go in the above case, though
individual (browser) implementations are free to use something else if
they want to.

I must admit I have not yet read the algebra draft, but on general
considerations I would agree with Ted that q factors have nothing to
do with registration.  I see q factors as optional things which may be
present in some negotiation protocols, with protocol-dependent
semantics.  If you want to specify semantics for some number when
registering a tag, this number should be in the tag value, not in a q
factor.

On the subject of calculations with q factors: I see this as a form of
fuzzy logic.  Experience with fuzzy logic shows that it often matters
surprisingly little whether the 'fuzzy and' is a + or a *: reasonable
things happen with either one, and if an optimum exists it will be
found with either one.  So I don't loose too much sleep on the choice
of these operations.

>Regards,   Martin.

Koen.

---

From: Al Gilman <[email-masked]>
Date: Thu, 15 Oct 1998 14:00:54 -0400 (EDT)

> > > advance by a registration."

Let me amend my suggested wording to something on the order of
"[results of arithmetic on q-factors] are not defined by this
document and are likely to produce unpredictable results unless
suitably defined for the context where they are used."

It doesn't have to be by registration, true.

Al