Re: Proposed structure for media-dependent conformance

At 02:26 PM 12/16/98 -0500, you wrote:
>Hello,
>
>As per my action item in today's teleconf (raw minutes available
>at [1]), here is a proposed structure for how UAs can claim
>media-dependent conformance:
>
>1) The document lists a finite number of "media types", based on, but
>   not limited to, those defined by the CSS2 specification [2].
>
>2) In the guidelines document, each media type is defined (only) as a
>set
>   of priority 1 techniques. Thus, for example, the "tty" media type
>   (or perhaps the term should be "UA type") 

Let me offer UI profile as a technical term that is correct and let the
editors worry about how to explain this to readers.

The point is that this is one step removed from media types as used in HTML
and CSS and so we should not use the same term. 

A UI profile states what resources are available for interaction with the
user, preferenably in terms of a rough capability bin and not too exact
detail.  In other words all color graphics displays of greater than eight
colors and greater than 640X480 pixels could be treated as one capability
bin (not less than 50 Hz refresh, ...).

Note that the media types as used in HTML and CSS only pertain to the
display function.  The failure modes that keep people from using the normal
mouse command IF of the GUI desktop computing platform can be either in
inability to control the mouse or in inability to interpret the screen
cursor.  The mouse command sub-function in the GUI is a closed loop of
display and control sub-functions; a failure in any of these sub-functions
breaks the loop and defeats the composite function.

Text plays a central role in display diversity because of all data
representations in current use, it has the widest fanout across display
media.  Likewise keyboard commands have a comparable central role in
command diversity because AT to map alternative devices into keyboard
emulation is highly developed and widely available.  So mapping keyboard
commands into alternate devices is readily attainable by the user.  Mapping
other command modes into suitable alternative devices is more risky.  This
is parallel to why we shadow video with audio descriptions and text
descriptions.  The video only works for a narrow class of devices; the text
is more mappable to alternatives.

The content we have to presume is multimedia.  The trick is to map the
constellation of content components into the constellation of UI components
that are in the user's selected/adaptive profile.

I think we are getting somewhere if we define UI profiles as collections of
device capabilities.  HTTP/CSS media classes are examples of device
capabilities. Including a device capability in the UI profile means that
the software can expect the user to use this capability.

Then for each profile analyzed, you can come up with a corresponding
technique profile of the minimum techniques needed to be effective in this
UI profile context.

Then for each software product, it can claim it supports X UI profile
natively (because it implements some superset of the minimum techniques)
and Y UI profile
through adaptability (if it supports an add-on interface and there are
widely available add-ons which take this interface and complete a UA
configuration providing the rest of the necessary techniques for Y UI profile.

Because the UI techniques actually depend on closing the loop through
multiple devices, I think we need to treat conformance in terms of UI
profiles, not UI components individually.

Al

Received on Wednesday, 16 December 1998 15:38:51 UTC