[Zope] Re: [Zope-dev] Multiformatted Interface (was Re: [Zope] Can't add "date" property to new ZClass) "date" property to new ZClass)

[Michel Pelletier]

Rik Hoekstra wrote:
> 
> >
> > I'm working on a model and elaboration of what I call MFI, Multi-Format
> > Interface, which will be a component of the Portal Toolkit and possible
> > a future core feature of Zope. Basicly, this consolidates all of the
> > document types, DTML, XML, PDF, what-have you, into a subclassable
> > interface that allows you to define pluggable format types.
> 
> That is a very good idea. Should it be able to guess what the
> document format is or will you have to indicate that by hand?

It can be indicated on the managment screen, specified programaticaly
through DTML, and I suppose it would be nifty to have it sniff an
uploaded content type and select a formatter, for example, if you FTP
upload a file called whatever.xml, Zope will magically turn it into an
XML document instead of a DTML document.
 
> I doubt it. The structured documents and the page oriented markup
> seem to be rather different philosophies of representing a text
> document.  Turning PDF documents into html is no easy business
> either. But then, some sectioning of even a pdf document (and even of
> Word documents - sometimes :-) _is_ possible. Calling that a DOM is
> stretching the DOM concept a bit too much I think.

I'll take your word for it, I dont know much about it.  I'm sure it's
possible to do a minimal amount of parsing for properties etc or to just
have a null formatter in place for future expansion.
 
> What all documents do/could/should have (natively or added) are
> document properties (preferably conforming to the Dublin Core, for
> standardization). These should be extracted using DOM or COM (for
> Word documents) or via a PDF parser for PDF documents or whatever and
> added to the propertysheet. Or/and propertysheets could be filled by
> hand through the Zope Management interface.

We are working on making CatalogAwareness dublin-core standard, in fact
i think it's checked into CVS right now, but it might not be.
 
> I take it that your proposal also leads to inclusion of documents in
> catalogs for fielded and fulltext searches? Yes, please?

This will be a seperate mix-in class for portal aware objects.  For
example, News Items, How-Tos and tips will all subclass both MFI and
PortalObject.  PortalObject defines portal behavior like membership,
cataloging, dublin properties and reviewing.
 
> However, won't this be conceptually difficult beyond full text
> searches? The level of access of the documents are so diverse.
> Compare the structured DOM access to XML documents to the (basically)
> mere word level access to pdf (and even html) documents.

ZCatalogs would either have to be instructed to understand the deeper
structure of these types of doucments, or the documents themselves
(through PortalObject) will need to told how to compose their 'content'
into something the catalog can turn into values.

-Michel