Jake, (cc'ing j-users@xerces.apache.org which is a better forum for these questions. You should send follow ups there.)
Jacob Kjome <[EMAIL PROTECTED]> wrote on 07/24/2006 12:35:55 AM: > 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)? If you change the value of document-class-name from its default you don't get deferred node expansion regardless of whether the value of the feature is true. That is what's stated. It's a warning to users that deferred node expansion and plugging in an alternate DOM implementation are mutually exclusive. > 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. That's just how it works. For the history you'll have to ask the older (and probably former) developers. I wasn't around back then. > 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? I don't recall this ever being discussed so I wouldn't assume this was a conscious decision, however I imagine the benefit folks may get from doing this work would be outweighed by the maintenance cost (duplicate code) and increased footprint (HTML/WML DOM is already considered bloat by many users). > >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 nodeid 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? I don't think this was ever in my memory :). There's no concept of a template in the Xerces implementation. The deferred DOM table representation is for building one DOM only and I'm pretty sure the table destroys itself as the DOM is expanded to reclaim some memory. Also there's no way to jump to a node in the middle of the DOM without having its ancestors (and probably the immediate children of those ancestors) expanded. > 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] 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]