Michael L. Norton wrote:
Just because we *can* dynamically pull out a single page from the whole of a large XML file doesn't mean we *have* to.
Maybe we don't *have" to, but we certainly should. If we cannot handle such a task dynamically, then we are forced into adopting one of several clunky solutions. James suggests that we introduce redundancy into the mix. But in so doing, we now are faced with issues of synchronization. What happens when changes are are made to the document? Any change made to the "master" must be reflected in all derived versions. So one must either edit each of the generated versions to include the change (which will almost guarantee the loss of synchronization) or re-generate the reduced, and redundant, versions of the document after any change. Again, loss of synchronization is bound to result (as it relies on a human being to remember to do this). Indeed, any system that relies on the proper functioning of human beings will surely fail at some point.
I agree with Peter Robinson. A dynamic approach is always best.
I understand, and agree, that in theory a dynamic approach from a single source is preferable to creating static files. I don't think there is really such a problem of synchronization that you suggest, however. When changes are made in the 'master' document, this isn't going to be the copy of the document that is currently being used to dynamically create pages on the production server. The copying of this document to a production server is a single step -- whether that step involves a single process or a whole set of them is not really fraught with problems. If I type 'make site' I don't need to know that my Makefile (or whatever technology you prefer) is first making a backup of the current site, then copying any changed files into CVS for the production server, then recreating a whole series of expanded page files, or whatever. It is all still a single step.
But that is really tangential, the problem I was really envisioning is with really really large XML files, perhaps gigabytes in size. It doesn't matter that it is possible to produce single pages dynamically from such a file using XSLT, because the time and resources to do so reliably on a high-traffic website will make it painful for your users. In such cases then a solution like Peter's is better for dynamic creation of pages. However, I still argue that it isn't necessary to have this perceived division between 'master' file and individual page files. What about such things as xinclude? So you have your master file, but it is only filled with xinclude pointers to each of your individual page files. You make all changes on the individual files, if you need to search the whole thing or whatever you use the master file with xincludes expanded. (Or, my preferred way, would be the reverse, you make all the changes in a single master file which then is used to generate the site consisting of an xinclude-based master file and the individual page files.) Since the master file doesn't contain the all the individual page files, there is no redundancy. (Except, of course, between your working copy and production copy and backup copies, but that just makes good sense!)
-James