################################################################ $RCSfile: TODO.txt,v $ Authors: Chip Morris, Craeg Strong, Philipp von Weitershausen $Date: 2003/06/13 07:56:40 $ ################################################################ High Priority Processor Issues - Fix freezes and timeouts when accessing relative URLs in libxslt, pyana, and sablotron. Use asyncore or worker thread? This is an area of ongoing investigation... - SabPyth: does 0.98 fix xsl:import bug? - Pyana 0.8: lockup when accessing objects via relative URL - Libxslt: timeout when accessing objects via relative URL XPathMethod -- a new kind of object that applies an XPath expression to an XML document. XSLTMethod -- Make the XSLparameters, XSLparameters, and URNnamespaces built in properties so we don't have to remember how to spell them, and because explicit is better than implicit. XPointerMethod -- a new kind of object that applies an XPointer to an XML document. This may not be applied to an object in the same way as the other types, because the URL may uniquely identify the zope object. XMLSchemaMethod -- A new kind of object that applies an XMLSchema to an XML document. XQueryMethod -- A new kind of object that applies an XQuery to an XML document. XUpdateMethod -- A new kind of object that applies an XUpdate to an XML document. Schema Validation -- via DTD and/or XML Schema; does this more properly belong to the ParsedXML object? Alternative Input methods -- add ability to accept DOM and/or SAX events instead of ASCII only. Can this improve performance? 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 Medium Priority Alternative to __call__ or index_html() Provide ability to call an alternative method to obtain the source from the XML object and/or the XSLT object. Pipeline Cache Coherency -- In the case of a pipeline, make XML Method cache smart enough that if either the xml source or xslt source is *itself* a method, that it actually queries those objects for up-to-dateness. Today, the cache manager only notices if the leaf of a pipeline is out of date. Perhaps the best way to accomplish this is to override the bobobase_modification_time() method to return the most recent time of, self, the xml source object, and the xslt source object. Pipeline Caching -- In the case of a pipeline, we only cache the last value. The sources do attempt to cache their contents, but since the URL for the entire pipeline is the final URL, each result gets written out to the same file, with the final value on top. We need to either a) figure out how to separately cache each portion of a pipeline or b) only cache the final segment of a pipeline. (a) would ultimately be preferable, because the first portion of a pipeline could be an extremely expensive transformation. What if later sections changed but its sources did not? XSLT Parameters -- Each XSLT transformer may have zero or more xsl:params that parameterize the transformation. Somehow make XSLTMethod aware of those (parsing? ick.) so that you could dynamically query an XSLTMethod and find out the list of parameters and actually produce a form on the fly to fill them in. Basically marry Formulator and XSLTMethod. Caching improvements -- what about the ZPT that invokes a transformation like so "tal:attributes=here/src/xslt"? How can we know to re-run the transformation if the ZPT itself changes? Also XSLT parameters. When a parameter changes, the cache should be invalidated. Support xml-stylesheet processing instruction -- If we had a genericized XSLT component (a la Zope3) we could support xml-stylesheet processing instructions. We could have a notion of a default XSLTMethod that would be applied to any XML content, and the xml-stylesheet processing instruction could be used to either set that default or override it, depending on how it was designed. Blue Sky - 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. @@this needs to be fleshed out more@@ Done (PvW) - DynamicSource -- It would be useful if XSLTMethod 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 - ParsedXML and File compatibility -- Provide an optional method to call on either object to obtain the source, using __call__ as the default. - 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 Withdrawn (PvW) - The next logical step would be to allow supplying XSL on the fly: http://MyFolder/myZSQLmethod/asXML/transform/myXSL Reason of withdrawal: too complicated, goes beyond the Zope understanding of composite URLs (although that is a matter of taste). This proposal goes into the direction of Zope3's understanding of a service or an adaptor in general, respectively. Components are a good feature, but they are not part of Zope2... - Change the icon for an XSLTMethod depending on its behave_like. Reason of withdrawal: too playful and not consistent with the option to behave like the source object - Possibly provide the ability to cache the transformer and cache source for reuse (in the case where they are static) Reason of withdrawal: if the result is cached, why should the transformer or the source be cached, too? Sounds like overkill to me. - Improved Mime Type Support -- figure out which mime type the transformer is producing and make the resulting DTMLMethod or PageTemplate reflect this. Reason of withdrawal: Sounds like a nice plan, but setting a small content_type property on the developer's part sounds better to me than "figuring out" somehow what the transformer is producing. Besides, we still want to leave some programming to the site developer :) - 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. Reason of withdrawal: I never understood why the transformer property was a drop-down selection box and not a text field in the first place. If you know what transformer style sheet you want to use, you also know it's ID! Basta! - RestrictableMetaTypes -- Add ability to restrict the meta types of objects that can be placed inside a Transformer Registry. Borrow code from OrderedFolder? - Default Transformer -- Add ability to specify a default transformer in the TransformerRegistry. That would remove the need for an instance of XSLTMethod to specify a transformer-- The "add" form would always come up with the default instance selected. Reason of withdrawal: Transformer Registry is gone. away. /dev/null. Maybe somebody can explain to me what the reason of this Registry was in the first place. Sounds like giving too much control away to a folderish object. Withdrawn (CKS) - 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 method). Advantage: we needn't create dummy "reference" documents to pull out a piece of a larger document. Include ability to validate vs DTD, either an external DTD or one mentioned in the code. Reason of withdrawal: Superceded by XPathMethod and XPointerMethod objects. I think they represent a lighter-weight and more flexible way to solve the same problems.