Re: cardinal q-factors

[Al Gilman <asgilman@xxxxxxxxxxxxxxxx>]

to follow up on what Ted Hardie said:
> 
> 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.

> > 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.

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