RE: longdesc media type concern

At 03:01 PM 9/6/99 +1000, Jason White wrote:
...
>For example, do we have a
>guarantee in advance that all document markup languages, based on XML
>for example, will be subtypes of "text" (E.G. "text/xml",
>"text/xhtml", etc.)? If not, then there are good grounds on which to
>conclude that the best means of regulating LONGDESC does not consist
>in specifying a constraint in terms of the internet MIME type of the
>destination resource.

Two points that are in support of Jason's view:

First, we already have a draft specificataion of an XML application
that its MIME type is not text/* . It is Scalable Vector Graphics,
and the proposed MIME type is image/svg. 

The concept of MIME type tells very little about the accessibility 
features of the resource, or even of its general features, for example
text/* means that if the resource cannot be processed, then rendering 
it as plain text could make some sense to a human reader. 

This criterion has little to do with accessiblity. As we are actually 
assuming that longdesc refers to resources that are processed. Moreover 
in the definition of the text/* it is implicitly assumed that a human
reader can 
scan through the code and find the human language bits in it (e.g.,
text/html), 
or understand the code itsself (text/javascript). Both "tests" have little
to do with accesssiblity.

In addition, an "application/pdf" file that contains mainly text streams that 
their order in the file is the same as their logical reading order, and
utilizes 
compression can not be understood when rendered as plain text (because of the 
compression). But the text can be extracted and presented reasonably well
(due to the 
logical reading order of the streams) in a speaking device. 

Regards,
Nir.

===================================
Nir Dagan
Assistant Professor of Economics
Brown University 
Providence, RI
USA

http://www.nirdagan.com
mailto:nir@nirdagan.com
tel:+1-401-863-2145

Received on Monday, 6 September 1999 12:24:43 UTC