>There are those of us who work in environments with several hundred web
>authors who don't necessarily have access to the conversion tools. For
example, I work for a university with many many web
I was one of those people for a number of years, working too as a University
webmaster. I don't understand why you are arguing with my point. All I said
was that *if* your documents don't change that often, batch conversion of
what's changed is better than converting on the fly. I was merely
questioning the need to convert on the fly *in all instances*.
> Most of
>these people use FTP to upload documents. I'm currently working on a side
>project to put an on-line publication we product on the Web in XML format.
I started introducing this at my university in 1996 and used batch
conversion via perl script.
>A larger project in the works involves a campus-wide specialized
>application of XML. Until the browsers widely support POX (Plain Ol'
>XML), we need to serve up documents most user agents can read. Hence we
>need some way of automatically converting these documents into HTML.
That's exactly what I was suggesting. I was arguing *against* conversion on
the fly and *for* batch conversion (preferrable automated and only on
changed documents, hence the suggestion of make)
>I suggest a hybrid approach. How about an Apache module (or Java servlet,
>or whatever) that compares the modification time of the HTML page to the
>modification time of the XML page and only generates the HTML when the XML
>has been changed.
If you have a small number of documents (or even a large number that don't
change very often), make is probably sufficient. The idea you are talking
about would work quite nicely with situations where only a small proportion
of documents are requested most of the time.
>This comparison would take significantly fewer cycles
>while still essentially allowing for on-the-fly parsing. It's a very
>simple caching mechanism that would satisfy the previous author's needs.
Perhaps. I don't recall the previous author giving enough information about
their needs to tell whether they need on-the-fly conversion. That was my
point. From a usability point of view, it is a bad idea to convert on the
fly if the document doesn't change much. At my university we had XML
documents that were converted to 10,000+ HTML documents. The conversion only
needed to be done once a year unless there were corrections to the odd page
(in which case only dependant pages needed to be reconverted). Conversion on
the fly would have been the wrong thing to do in this instance.