Re: ALT content question

  From: Daniel Dardailler <danield@w3.org>
  
  > Descriptions for sensitive maps should also embed all the links
  > in the map.
  
  Client side image maps solve the problem using a different but similar
  mechanism.
  
If the client-side image map only lists the links and
coordinates, it may not fully capture what the image adds to the
set of links.

Sensitive maps often have an image which organizes links into an
array or other graph where the alignment connotes semantic
relationships.  The client side maps are familiar to Lynx users,
and work now as a list of links.  But this fails to capture the
graph semantics that the visual display connotes.  What I am
saying is that the highest and best description for a sensitive
map is one which provides all the functionality of the user-side
image map [list reduction] and adds back (in the textual
voice-over) the relationships left out of the graph by the
reduction to a list or tree.

  > As the size of the display pipe
  > goes down, more and more of this infrastructure wants to migrate
  > into implicit information displayed only on explicit request and
  > not be presented in the default "display" view.
  
  One would hope that Style sheet will help achieving that.
   
The work that has gone into styles will definitely help, but I
think that some entrenched assumptions may have to be relaxed to
get to a framework that is robust enough to solve the WAI problem.

My current estimate of what it is going to take is
	
	- collect styles, fonts, jargon dictionaries, etc.
		under a "method library patch" class
	- ensure that the method primitive (base class for methods) 
		includes the capability to mix and match 
		acceptors (rules, demand) 
		and producers (supply, reductions, glyphs)
		producers migrate toward the information reader, 
		acceptors toward the writer.
	- nuke the assumption that the application of these
		generalized style sheets can be 
		monotonically ordered (i.e. "cascading" has to change to
		"composable")

  > Appropriate accomodation of browsing is not just changing or
  > stripping fonts.  The focus or viewframe is going to be scoped
  > differently, as well.  Not only breadth of topic but in depth of
  > detail, as well.  One way is for the content form to contain
  > priorities and the preferences to play off the priorities to
  > prune the data presented. 
  
  I'm not sure a priority schema is required, vs. the existing
  presentation/structured-content dichotomy that SGML is championing.
  
I'm not sure that priority data are required in the documents or
in the user preferences that come forward from client to server.
But I think that a system of performance parameters and [weights
or ordinal prioritizations] would be an immense aid to us in
rationalizing what we can learn from browse modes that we can put
in the lab today as a way of predicting the acceptance of browse
modes [and resource forms] that we project for a future
solution.

I posted earlier on this issue.  I think that I may have used the
term "factored."  In any case, I have concerns about the
prognosis for content/presentation dichotomy.  Some of my
reservations are as follows:

There is no a_priori "true" or universal partitioning between
content and decoration.  One man's essence is another's
periphery.  Further, abstraction costs.  

Eventually what we come up with as a model of "core information"
is going to be a compromise not only among the preferences of
users from different browse mode perspectives but also between
universality ethics and market-following curtosis.

An alternative to factored content and representation data is to
annotate something which is very close to the surface form of one
browse mode with enough non-presenting relationships so that an
agreed core model can be reconstructed.  Then the client
operating in another browse mode can provide realization [style]
from defaults for the majority of content and from
server-provided alternatives in the minority of cases where the
information source wants to take the extra trouble to optimize
their message in multiple browse modes.

This makes the browser which is capable of off-nominal browse
modes "thick" because it has to reconstruct the semantic model
from the [enriched] presentation form.  But it minimizes the pain
at the information-source end.

As I have said before, I don't know the actual answer between the
above two sketches of alternatives.  Some hybrid may also be the
ultimate solution.  But I do think that we need to understand
that we can defer the above choice of implementation if we can
learn how to deal with the browse-mode-diversity issues and come
up with a generic content model first.

  [Al spoke of navigation infrastructure melting into the woodwork
  in narrowband-display browse modes.]

DD:
  Good point.
  I guess something in the line of LINK and meta-data is needed (more
  semantics in the markup).

What I can say for sure is that we need more assured integrity of
content relationships as made available to the browse process.  I
do think that standardized LINK relationships (if we can get them
robust enough) are close to something that we ought to do.  I am
unclear whether more markup or more communication is the best way
to deliver the full model to the client.

I do think that one of the topics we need to research in the name
of "requirements" is a class-structured taxonomy for the
relationships exemplified by current-day LINK tags.  It has to be
a multi-level sort, because the 12-key command vocabulary doesn't
allow for as many options as a page-expanded GUI button bar, for
example.  Out of 12 keys you get 10 short commands of which only
say 4 can be standard functions.

Thanks for your careful reading and thoughtful responses.

--
Al Gilman

Received on Tuesday, 10 June 1997 12:56:03 UTC