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

$RCSfile: TODO.txt,v $

Authors: Chip Morris, Craeg Strong, Philipp von Weitershausen

$Date: 2003/03/30 03:45:47 $

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

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.

  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.
