Re: The great "kill-scrollkeeper-with-a-blunt-spoon" Proposal

[Don Scorgie <DonScorgie Blueyonder co uk>]

Hi,

On Wed, 2006-07-26 at 19:45 -0400, David Malcolm wrote:
> Advocating extreme simplification: what do omf files actually give us?
> When would you use them?  Maybe I'm just being cynical (short-sighted?),
> but I don't see much use for them.  I read through the list of existing
> fields, and I don't see what most of them give us.
> 
> What is it that we need from a document or document metadata to be
> useful?
> (i) when searching for a document, or giving a list of documentation
> available on the system, we need name, description, language and
> keywords, beyond that, it seems like ontological onanism to me
> (ii) when displaying a specific document, then other information can be
> useful e.g. the bugzilla component stuff - but why not just grab this
> direct out of the document itself?
> 

We definitely need some form of metadata storage.  Since the library is
intended for easy migration from scrollkeeper, we have to use the same
structure and filetypes it uses, which means we inherit omf files.

I agree that most of the fields are pointless but the two bugzilla bits
were added to the proposal to save having to scan through the document
to find the information (since, we don't currently scan the doc, we just
pass it to the XSLT).  Plus, which is easier for the client apps:
scanning through the doc looking for bugzilla info, or calling a
function in the library that passes back the desired info?

Maybe the other fields, the pointless ones, could be ignored by the
library / tools and marked as depreciated (when 1 is encountered during
the install process, a warning spat out).  It is also possible that
other viewers have started using the other fields to store additional
information.  The seriesid and version are needed internally to know
which docs are related etc. and I can just about see that several other
seemingly bizarre fields may be useful (rights, type, format).

Don