Todo List

################################################################

$RCSfile: TODO.txt,v $

Authors: Chip Morris, Craeg Strong

$Date: 2002/11/06 19:13:56 $

################################################################

High Priority

Processor Issues

implement 4suite 12a3 catalog resolver
Evaluate Pyana failures on ariel website
libxslt python api for urn resolution
libxslt python api for catalog resolver
SabPyth: xsl:import bug fix, when support ext:evaluate?

DynamicSource

It would be useful if XMLTransform allowed me to leave the Source ID field empty and assumed it's applied to an XML. For example I would like to be able to write: http://MyFolder/myZSQLmethod/asXML/transform and get a rendered page.

This way transformer doesn't know how it gets its XML and behaves like a true pipe.

The proposed enhancement would let me to chain transformers: ....../asXML/transform1/transform2

The next logical step would be to allow supplying XSL on the fly: http://MyFolder/myZSQLmethod/asXML/transform/myXSL

FO to PDF via FOP

Add a "Fopper" object that can create PDF out of a FO document. Possibly use Java-based FOP via XML-RPC

XMLDocumentAssembler

a new kind of object whose job it is to assemble a well-formed XML document out of fragments. These fragments can be pieces of other XML documents specified via an XPath expression (i.e. a kind of a filter). Advantage: we needn't create dummy "reference" documents to pull out a piece of a larger document.

Medium Priority

ParsedXML and File compatibility: Provide an optional method to call on either object to obtain the source, using __call__ as the default.

Possibly provide the ability to cache the transformer and cache source for reuse (in the case where they are static)

Improved Mime Type Support: figure out which mime type the transformer is producing and make the resulting DTMLMethod or PageTemplate reflect this.
PropertyFiles: make default_transformer_meta_types, mime_types non_transformer_meta_types and choice of XSLTProcessor switchable at start time through the use of property files. Advantage: eliminates need to change source code. Steal code for this from ExternalFile.
XML Catalog support: incorporate support for XML catalogs for URI resolution. This will provide the ability to support custom URI (URN and/or URL) resolution strategies without having to change source code
RestrictableMetaTypes: Add ability to restrict the meta types of objects that can be placed inside a Transformer Registry. Borrow code from OrderedFolder?
DTD Validation: Add ability to validate against DTD via button in ZMI
Default Transformer: Add ability to specify a default transformer in the TransformerRegistry. That would remove the need for an instance of XMLTransform to specify a transformer-- The "add" form would always come up with the default instance selected.

Nice To Have

Change the icon for an XMLTransform depending on its behave_like.

Blue Sky

Add ability to use external DTD rather than mention in XML source code (?)
Add the capability to handle multiple binding times for XSLT transformer properties. For example, there should be properties at the document type, document instance, and site level. User properties could be specified on a session (for example via a cookie in the REQUEST object) or permanent (in ZODB?) basis and should override all others.

Withdrawn items

XMLTransformFolder -- Add a batch transformer with the ability to transform an entire folder full of "like" objects. For example, you could have a transformer that knows how to transform articles into HTML, and have a Zope folder full of objects that product XML articles. The transformer would use some sort of prefix to suffix mapping algorithm to do the transformations. It should probably be a folder-like object.
*This item has been obviated by the ability to apply an XMLTransform to a source file via acquisition like a python script or DTML method*