You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@xalan.apache.org by mi...@ca.ibm.com on 2003/02/19 22:08:42 UTC

Why does ResultTreeHandler ignore startDocument() calls?

I hope someone can enlighten me.

I'm trying to understand why ResultTreeHandler has a startDocument() method
with an empty body.  I essentially ignores all calls to its startDocument()
method.

It does however go to great lengths to generate a startDocument() call to
the ContentHandler that it contains.

Can't one just require that users of ResultTreeHandler have paired calls to
startDocument() and endDocument()?

ResultTreeHandler.startDocument() could do what
ResultTreeHandler.flushDocEvent() does and then one wouldn't have to keep
doing internal checking if ResultTreeHandler should call flushDocEvent().

Is there some sort of subtle ordering issue going on here?  Perhaps with
events that occur before startDocument(), or maybe something to do  with
SerializerSwitcher, that switches the underlying ContentHandler from XML to
HTML depending on the first element ( <html> or not)?

One such asymmetric place is
org.apache.xalan.transformer.TransformerImpl.transformNode(int node), that
only calls endDocument() on ResultTreeHandler.
        try
        {
          this.applyTemplateToNode(null, null, node);
        }
        finally
        {
          xctxt.popContextNodeList();
        }
        // m_stylesheetRoot.getStartRule().execute(this);

        // System.out.println("Done with applyTemplateToNode - "
+Thread.currentThread().getName());
        if (null != m_resultTreeHandler)
        {
          m_resultTreeHandler.endDocument();
        }



Brian Minchau
XSLT Development, IBM Toronto
e-mail:        minchau@ca.ibm.com

Re: Why does ResultTreeHandler ignore startDocument() calls?

Posted by Joseph Kesselman <ke...@us.ibm.com>.

To produce reliable SAX output, ResultTreeHandler must pass 
startDocument() out.  We *could* process startDocument() and then only 
generate a startDocument() if one wasn't passed in... but that may be more 
work than saying we will always generate it ourselves.

At this time, ResultTreeHandler is not always passed startDocument(), 
depending on the structure of the tree being passed into it. I believe we 
actually concluded that was unavoidable in the general case... but it's 
been a year and a half since I've looked at that issue.

There may also be gratuitous asymmetries. OR stuff implied by lower-level 
routines that really wants to be left there.

If someone has the cycles to investigate this, go for it. 

______________________________________
Joe Kesselman  / IBM Research