lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Internal MIME types


From: Christopher R. Maden
Subject: Re: LYNX-DEV Internal MIME types
Date: Mon, 28 Apr 1997 15:33:55 GMT

[Klaus Weide]
> Why is it advantageous to build and keep in memory a whole document
> in premasticated (parsed) form?  Specifically, for a program like
> Lynx.  Is parsing such an expensive process?

No, but one of the big advantages of a rich markup like XML is the
ability to apply different stylesheets to the same document to present
different views of the information.  Storing an abstract
representation of the data, instead of Lynx's current habit of storing
the screen representation, allows re-application of a stylesheet to
generate a different screen view without re-fetching the document.
(Parsing is not necessarily expensive, but fetching can be.)

> I can see how this is useful or necessary if the structure will be
> modified by the application, but Lynx is not an editing tool.  (I
> could come up with delayed processing of HTML tables, but I am
> curious about a more general response.)

Not that the structure is modified, but that information is requested
from it.  We could cache the source and re-parse it, but we may as
well store the parsed information if it isn't too large in memory.

> If I understand you correctly, you are talking about some structure
> in memory that would be created by one stage of processing (parsing)
> and then read by (an)other stage(s).  Those next stage(s) would have
> to traverse the structure and generate (eventually, in the case of
> Lynx) calls to functions of the display engine from it.

Yes - that second stage would be the styling and link interpretation
stage.

> The role of that data structure seems rather different from what
> MIME types are used for in the Lynx code
[...]

The internal MIME types were a guess, because I didn't have the
information I needed.  Now I do, as per my last message; the important
thing was triggering a new parser, and now I know how to do that.

> What useful things would those (hypothetical?) tools do for Lynx
> users?

A Web speech renderer written on top of the DOM interface would be
useful to blind users with access only to Lynx and not to GUI
browsers, to dredge up one example.

> How does it further the goals of the Web *Access* Initiative?

Access first needs information to access.  DOM provides more
information about a document to which one can have access.

> [  And I hope it is not a way to drag us all into an Internet-wide
>    "Share your preference folder with our sponsors!" initiative...  ]

I'm not sure what that means.  The WAI is sponsored by the
U.S. government, the EC, the Japanese government, and the Yuri
Rubinsky Insight Foundation.  There are software vendors as major
sponsors, but I think it will be the least specific-vendor-focused
thing the W3C has ever done.

-Chris
-- 
Christopher R. Maden                  One Richmond Square
DynaText SIT Technical Support        Providence, RI 02906 USA
Inso Corporation                      +1.401.421.9550 (voice)
Electronic Publishing Solutions       +1.401.521.2030 (facsimile)
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]