[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