[jdom-interest] Protected methods to make private

Laurent Bihanic laurent.bihanic at atosorigin.com
Wed Jul 2 08:02:51 PDT 2003


Bradley S. Huffman wrote:
>>Second, when the processor invokes endDocument (e.g. Xalan, Saxon, jd.xslt), 
>>the content of the result list may not be suitable to create a well-formed 
>>document as it may contain several elements.
> 
> So those processors will invoke startDocument and then invoke a series of
> events that don't form a well-formed document, or invoke a endDocument
> without a corresponding startDocument. Oooo, that sounds bad.

No, they always invoke startDocument and endDocument, as requested per the SAX 
specification. And the XSLT spec. says that the output of an XSL 
transformation is a result tree, not a well-formed document.

> Delay creating a document until getDocument and if it throws a exception
> catch it and return null, that should work.  On a call to getResult would
> you expect the document's content or for the returned List to be size == 1
> and index 0 to contains a actual Document object?  I think the later.

OK for delaying the creation of the document. The getDocument method in 
JDOMResult is just a convenience method that tries to create a document from 
the XSLT result and returns null if it can't. It's usage is discouraged unless 
you're 100% sure the XSLT stylesheet actually produces a document.

As for getResult, FragmentHandler does not have the problem of deciding 
whether to return a Document or a list of nodes as the result of an XSLT 
transform is always a list of nodes. Thus getResult never returns any 
document: The returned list can only contain Element, Comment, Text and PI 
nodes. With your new WIP SAXHandler, it may also contain a DocType node.

> The default array size of 5 seems to be good 80/20 for most elements except
> maybe the root element.  So I also want to try buffering the root element's
> content and delay the root element creation until endElement is invoke to
> see if it helps on larger documents or just adds to much complexity.

I don't understand why you want to treat the root element in a different way? 
Document content differs from element content in that it allows a DocType 
node, only one element node and no text node. But that one element node is 
just a regular element.
Replacing the root element by a set of lists (children, attributes, 
namespaces, etc.) will not save any memory, IMHO, but the prefix resultion for 
the namespaces in scope will get a little bit tricky.

Laurent




More information about the jdom-interest mailing list