--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: Finn Bock [mailto:[EMAIL PROTECTED] > > > > > [Andreas L. Delmelle] > > > In this case, however, I think you > > > can't fully 'push' these onto the descendants, > as this would > > > lead to absurd storage-reqs for quite > average-sized documents. > >
<snip/> > > > > Absolutely correct, and I'm not at all sure that > we should go to an array > > based storage of the properties in PropertyList, > as I did in the patch. One thing I'm missing here, for Finn's design below: values[0] = null // always null. values[1] = reference to a 'foo' Property instance values[2] = reference to a 'baz' Property instance Can't we just have, say, values[1] refer to the parent's Property instance in cases where inheritance is applicable? I.e., for all those references to the 'foo' property instance for the children of an FO where that value would be inherited, we don't have to create a new Property instance, just a reference to the inherited instance. > The difference would be that, instead of n > Property objects, each with > its own FObj, you would end up with one larger > Property object --larger, > because it has to store references of all FObj's to > which it applies - that > is in some way shared by n FObj's. > I think this could be done more simply by the above, just have values[1] refer to the property of the parent instead. But if the problem is the *recursion* necessary to determine the property instance to inherit--here, not the memory problem, but processing speed--I'm thinking of a PropertyWindow instance as follows: A PropertyWindow would be used temporarily during FObj property initialization to hold references to all the property instances that would be relevant for that FObj should a property not be explicitly defined. So, to populate the property instances for a particular FObj, i.e., the "values" array: 1.) read any incoming attributes and make properties out of them. 2.) for any properties undefined, access the PropertyWindow to determine the property instances to use for them. No recursion needed now. 3.) if the FObj has any child objects, create a new (temporary) PropertyWindow for their processing, based on the FObj's (parent) PropertyWindow and the value of its own Properties. This temporary PropertyWindow can be dropped once the children's FObjs have been processed. So the number of open PropertyWindow instances during processing would just be equal to the depth of the tree at the current point of processing. (What I'm describing above is may very well be a common design pattern, I don't know its name, however.) OTOH, for any XSL functions which request, "run-time", to use different Property values than that obtained by simple inheritance--we can't rely on the above. These functions are relatively infrequently used, and IMO do not need to be as optimized as normal inheritance would be--i.e., we still have to support them, but we shouldn't be altering the speed of the base processing in order to optimize for *these* functions--recursion would be OK here, if it allows speed/memory saving for usual processing. Glen __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
