[
Lists Home |
Date Index |
Thread Index
]
> I'd like to point out that a compound processor works only if you know
> what the task is. That is, the task is an important piece of processing
> context that is not part of the document.
For sure, but that's really out of scope for what I'm doing. The "task"
should be understood before the stuff I'm specifying happens.
> Are there any other generic tasks beside display?
Sure, there's an infinite number; edit (as you say), convert, compress,
summarize, reverse, encrypt. Basically, anything you can do to a blob
of data.
> This is important because the notion of such generic processors sits
> behind at least some of the resources enumerated by a RDDL document.
> It's fine if you can use them to display/edit the document, but I'm a
> bit skeptical that you can use them for anything else.
Consider "summarize".
For a compound document including XHTML & SVG, we could activate a
"XHTML summarizer" for the XHTML content, and a separate "SVG
summarizer" for the SVG content. The end result is a summarized
version of the whole document. Right?
Ditto for every other task. A compound editor could activate an SVG
editor in-place within a WYSIWYG XHTML editor. A compound compressor
could activate compressors optimized for each namespace, yielding
superior compression. etc..
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@planetfred.com
http://www.markbaker.ca http://www.planetfred.com
|
