[
Lists Home |
Date Index |
Thread Index
]
On 4/15/05, Liam Quin <liam@w3.org> wrote:
> On Fri, Apr 15, 2005 at 01:03:13PM -0500, Peter Hunsberger wrote:
> > On 4/15/05, Michael Kay <mike@saxonica.com> wrote:
> [...]
> >> It's not difficult to do it. It's just difficult to do it in such a way that
> >> you can reassemble a shredded document of any size before the kettle has
> >> boiled.
>
> [..]
>
> >
> > Don't know what you mean by "any size", but in our current case we
> > have one screen that has about 9 documents some of which are several K
> > in size.
>
> I used a "shredding" system (I didn't design or build it) working on
> aircraft manuals once. A "tiny" document was about 5 megabytes of
> text (i.e. not including graphics) and took 45 minutes to copy on a
> high-end SPARC server. Documents with 150,000 pages were not unheard
> of in that industry, although 10,000 was more common. You get similar
> complexity in other industries, and it's why they turned early on to
> using SGML as part of their document management strategy. "Just go
> through 150,000 pages and change every part 2003 to part 1826, but
> be careful not to affect dates" etc etc, the story we all know.
>
> If your documents are only "several K" [Kbytes?] in size you have
> a lot more flexibility.
Sure, and that seems to be the main point of this perma-thread: you've
got to match the tools to the job at hand. No surprise there. (And yes
K == Kbytes).
My main reason for jumping in is to emphasize that we've had good
experiences with XML to RDB mapping and I don't think it should be
counted out by way of assumptions about performance or functionality.
--
Peter Hunsberger
|
