Re: Document Indexing -- How to index Dynamic Content?

> 
>   From: ianweb@smaug.java.utoronto.ca (Ian Graham)
> 
> | ... For example, my organization uses parsed 
> | HTML (*.shtml) for many home pages -- the parsing simply introduces 
> | a few lines of 'news of the day' text, with the majority of the 
> | document being invariant directory-like information for the site. 
> | We would like this page to be indexed by web robots, as they
> | represent useful indices for the site.
> ---
> 
> Several people have suggested splitting the dynamic part out to a
> separate page.  That approach would lose the critical advantage of
> making sure the dynamic information was visible to all users.
>
> This looks, I think, like a valid use for frames.  Put the dynamic stuff
> on a separate URL and load it into a sub-frame.  The main page would be
> static and indexable with a meaningful last-modified date.  This may
> actually be an answer to the often-asked "Has anyone seen a case where
> frames are actually valuable?"
> 
> An alternative would be to use Java or JavaScript to download the
> dynamic information into the otherwise-fixed page, or (more crudely) to
> turn the dynamic information into a GIF and include it as an img...
> 
> Which approach is preferable depends on the browser mix you're serving
> and on the relative volume and weight of the dynamic material (since the
> framed approach would dedicate a fixed part of the window space to its
> use).

We rejected frames because of the context -- the dynamic content is small
and is an integral part of the document's text. Putting it in a frame 
made for a very unwieldy (and unprintable) page.   Also, we need to 
support users with frame-incapable browsers.   The inserts are text, so 
that an img is not appropriate (and messes up lynx users).   Java 
would be nice, except that for us, the solution must work for everybody
-- includingon Win3.1 machines, and lynx. 

Essentially, the content design and layout can done perfectly well 
using HTML 3.2 , without any frame, java or javascript extensions. Why
should authors be forced to use all these complicated extensions, when
a simple HTML feature could resolve the problem?

THe question to my mind is -- is this a sufficiently common issue that
warrants an HTML-based solution?

Ian

> scott
> 
> --
> scott preece
> motorola/mcg urbana design center	1101 e. university, urbana, il   61801
> phone:	217-384-8589			  fax:	217-384-8550
> internet mail:	preece@urbana.mcd.mot.com
>

Received on Thursday, 7 November 1996 13:02:18 UTC