Subject: Re: Colour features

From: Graham Klyne <[email-masked]>
Date: Fri, 13 Nov 1998 16:41:17 +0000

At 10:45 13/11/98 -0500, Al Gilman wrote:
>to follow up on what Larry Masinter said:
[...]
>Making all silly states illegal will make some useful states 
>unreachable.

As far as I can tell, Larry's suggestion does not make any states
unreachable.  In my view, it reduces duplication with a more detailed
colour description by describing the most coarse-grained of colour-related
features.  This effectively creates a number of subspaces within which
colour information may be described more precisely.

This proposal does not preclude any more detailed colour information.  What
it does do is allow some useful descriptions in situations when more
detailed information is not required or is unknown.

>The following is just an impression, but it would seem that the
>information model previously suggested may be rich enough to
>state the color resolution capability of a color-weak user, and
>this enumeration would seem incapable of doing that.  I will see
>if we can get a reading from the Lighthouse on this.

The more detailed descriptions still allow colour gamut, etc. to be
expressed.  I note that what we don't seem to have (and never did have) is
some kind of colour-projection model to describe the abilities of a
colour-eak user.  I think that would properly be a work item for your
accessibility group to consider.

>The other problem is that I think I want to know opaque 3-D color
>from translucent 4-D color.  But that could be accomodated by
>replacing "full" with two more choices on the order of "opaque |
>semiopaque".

There's more.  But it's coloured by the proposed 'colour-space' feature,
which embodies both the colour space axes (e.g. RGB, LAB, CMY, CMYK, etc.),
and the particular colour-value to rendition mapping applicable to a device.

>Is it time to amend our concept of the technology proposal to
>include an initial batch of registrations as one of the
>components?  These items would not have the force of a standard,
>but would have registered definitions from the outset and relieve
>pressure on the standards-track RFC's to define things.  Can we
>have a registration-track RFC?
>
>Where this comes from is the following idea: If we were to go
>forward with the summary set of color grades, I would sure like
>to be more confident that the more elaborate scheme would work as
>a registration.  The wording of the registration should be
>a piece of the review package for the bundle.  Why not just make
>a few such registrations part of the package?

If I understand you correctly, this is broadly what we are trying to do
with the media-features and fax-feature-schema documents.  Except that they
are expected to have standard status, because other standards will depend
upon them.

#g

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

---

From: Al Gilman <[email-masked]>
Date: Fri, 13 Nov 1998 13:13:13 -0500 (EST)

I probably mis-read what Larry was saying.  I thought he was
wiping away the detailed model altogether and leaving only the
revised summary classes.

Your rewrite incorporating Larry's summary levels works for me.

I still wonder if you shouldn't expose opaque/transparent in the
top-level categories, but I would be happy to stick with what
people generally think on this.

Al

to follow up on what Graham Klyne said:
> From [email-masked]  Fri Nov 13 11:41:44 1998
> Message-Id: <[email-masked]>
> X-Sender: [email-masked]
> X-Mailer: Windows Eudora Pro Version 3.0 (32)
> Date: Fri, 13 Nov 1998 16:41:17 +0000
> To: Al Gilman <[email-masked]>
> From: Graham Klyne <[email-masked]>
> Subject: Re: Colour features
> Cc: [email-masked]