At 02:50 PM 7/23/2006, you wrote:
>Hi Jake,
>
>Jacob Kjome <[EMAIL PROTECTED]> wrote on 07/22/2006 08:08:22 PM:
>
>>
>> I noticed in the note for the document-class-name property that "When
>> the document class name is set to a value other than the name of the
>> default document factory, the deferred node expansion feature does
>> not work." Does this mean that Xerces checks specifically for the
>> class "org.apache.xerces.dom.DocumentImpl" in order to enable
>> deferred node expansion, or can a custom DOM implementation extend
>> from said class and still have node expansion enabled?
>
>Setting the document-class-name property to any other value than
>"org.apache.xerces.dom.DocumentImpl" will disable deferred node expansion.
>The only deferred DOM implementation Xerces knows how to handle is its
>own. It directly extends the non-deferred implementation (DocumentImpl)
>and is built using its internal methods. There's no mechanism for plugging
>in a different one.
>
>> For instance, is deferred node expansion disabled if the
>> document-class-name is HTMLDocumentImpl?
>
>The HTML DOM is on another branch of the class hierarchy (see below) and
>isn't capable of deferred node expansion.
>
What if the value of document-class-name was
"org.apache.xerces.dom.DeferredDocumentImpl"? If that wouldn't
trigger deferred node expansion, I don't know what would? I suppose,
though, that the feature defer-node-expansion is irrelevant in this
case, since it's already be made clear that said feature will be
used, implicitly. Is that right? So, why state that setting the
document-class-name to DocumentImpl could trigger usage of the
defer-node-expansion feature (the default is true, according to the
docs)? When defer-node-expansion is true and the document-class-name
is DocumentImpl, Xerces2 sort of ignores the the declared
DocumentImpl and, instead, uses DeferredDocumentImpl? Just seems a little odd.
Also, is there a reason the other DOM's aren't given the opportunity
to use deferred node expansion? Is it simply a matter of
effort? Couldn't DeferredDocumentImpl be abstract and then other
DOM's can have two versions, one extending DocumentImpl and the other
extending an abstract DeferredDocumentImpl? Is it just a matter of
the effort involved that no one is willing to do or is there some
technical reason it hasn't been done?
>CoreDocumentImpl
>|
>|__DocumentImpl
> |
> |__DeferredDocumentImpl
> |
> |__HTMLDocumentImpl
> |
> |__PSVIDocumentImpl
> |
> |__WMLDocumentImpl
>
>> I'm hoping it would work in either case or, more
>> generally, in any case where the custom DOM extends DocumentImpl.
>>
>> Also, if anyone on the Xerces team knows anything about XMLC's
>> LazyDOM, is the deferred node expansion feature equivalent to LazyDOM
>> or is it something a bit different?
>
>Xerces' deferred DOM creates nodes as they are accessed from a table
>representation which is constructed when the document is parsed. I've
>never heard of the XMLC LazyDOM so I don't know how that compares to it.
>
Do you remember Lutris and the Enhydra server? That's where XMLC
came from. It's now hosted by ObjectWeb. Mark Diekhans invented it
back in '99 (possibly earlier) or so and extended the Xerces1
DocumentImpl. Xerces2 DocumentImpl seems to work fine with it as
well. Here's a javadoc snippet from LazyDocument....
* A DOM Document that supports lazy instantiation of a template DOM. Nodes
* in the instance DOM are created as accessed. This can be either by
* traversing the tree or by direct access to a node by id number.
* Instantiation of nodes in the middle of the virtual tree is support. Thus
* a node can exist without a parent being expanded. This is used by XMLC,
* where the dynamic nodes tend to be towards the leaves of the tree.
* <p>
* Instances contain a reference to a DOM that is a shared template for the
* document. Each node in the template is assigned an integer node id that be
* used to index tables to directly look up the template of a node created
* from the template.
* <p>
* This DOM also supports associating pre-formatted text with some
nodes, which
* is used to avoid expensive string scanning operations during the output
* of unmodified nodes.
* <p>
* When a child of a node is requested, all direct children are expanded.
* This eliminates a lot of difficult book keep. Attributes are treated
* as a separate set from children, only instantiated when an attribute
* is accessed.
Does that jog your memory, or at least provide the info needed to
compare/contrast the DeferredDocumentImpl functionality with that of LazyDOM?
Jake
>>
>> thanks,
>>
>> Jake
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
>Thanks.
>
>Michael Glavassevich
>XML Parser Development
>IBM Toronto Lab
>E-mail: [EMAIL PROTECTED]
>E-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
