Can one automate the "lose the type indication by passing through the file system" hack by binding this image type to a viewer which is [a script which calls] Lynx which then keys off the file-extension casting?
I don't think that casting SVG to HTML is a good idea, however. Until Lynx has an XML/plain presentation mode such as the tree view in IE, you probably want to cast image/svg+xml to a viewer which applies a text transform to get HTML and then pipe it to Lynx. In other words, an XSLT partner of the SVG techniques, or a functional equivalent thereof written in Perl or whatever you think is broadly available on the same platforms with Lynx. Danny, yes the precedent and a pattern that many think should be preserved is that the type indication, like the BASE, is subject to a rule that the most local indication takes precedence. And the type indication in the HTTP Content-Type: header is more 'local' than the type indication in the referring document. See Martin Duerst's comment (20) to the SRGS grammar specification. http://lists.w3.org/Archives/Public/www-voice/2002JanMar/thread.html#94 [But then they don't want the typespace to change inside "a document."] On the other hand, forcing the processing to a valid supertype of the indicated type, as in forcing text/html to text/plain, and forcing any xml dialect to some generic xml processing, should be legal and a 'try harder' approach that assistive applications may employ. This is where we need to understand the valid limits on transformation vs. the artifacts of the author's personal predilections about expendable property bindings. Al At 03:29 PM 2002-03-22 , you wrote: >On Fri, Mar 22, 2002 at 08:22:22PM +0100, Danny Ayers wrote: >> Will this actually be presented as image/svg+xml coming from file? I can't >> see any mention in the trace (though I'm not familiar with these traces). >> >> I don't suppose you could try >> http://www.w3.org/TR/SVG-access/simplenetwork.svg ? > >hmm - this is a different problem - the server sets the Content-Type, which >makes it an image: > >HTMIME: PICKED UP Content-Type: 'image/svg+xml; qs=0.85' >HTMIME: Extended MIME Content-Type is image/svg+xml;qs=0.85 >LYmktime: Parsing 'Sat, 23 Mar 2002 02:23:37 GMT' >LYmktime: clock=1016850217, ctime=Fri Mar 22 21:23:37 2002 >LYmktime: Parsing 'Fri, 22 Mar 2002 20:23:37 GMT' >LYmktime: clock=1016828617, ctime=Fri Mar 22 15:23:37 2002 >HTMIME: MIME Content-Type is 'image/svg+xml', converting to 'www/present' >HTFormat: Constructing stream stack for image/svg+xml to www/present >HTFormat: Looking up presentation for image/svg+xml to www/present >HTFormat: comparing image/* and image/svg+xml for half match >StreamStack: found strong subtype wildcard match: image/* >StreamStack: found weak wildcard match: www/present >StreamStack: Using www/present >LYOpenTemp(,.svg+xml,wb) > >short answer: I don't know if there's a way to override that (that is, to >force that MIME type to be rendered as html). > >-- >Thomas E. Dickey <[EMAIL PROTECTED]> >http://invisible-island.net >ftp://invisible-island.net > >; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED] > ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
