Finn Bock wrote:
[Peter B. West]
Alt-design (trying the hyphen for a while) takes different approaches
at different times. While building the subtree of any node, all of
the properties are maintained in a HashMap, along with a BitSet of
specified properties.
When the subtree construction is c
[Peter B. West]
Alt-design (trying the hyphen for a while) takes different approaches at
different times. While building the subtree of any node, all of the
properties are maintained in a HashMap, along with a BitSet of specified
properties.
When the subtree construction is complete, the Hash
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
> If I mentioned PropertyValue singletons, it was a slip of the fingers.
> I maintain Property singletons, which are exist solely to provide access
> to certain "static" information about individual properties.
>
Don't
[me]
1) Only store the specified properties. That is what HEAD does now.
2) Put the relevant properties in a fast Property[] array and the
remaining specified properties in a HashMap. For fo:root the result
would be an array of size 1 for the 'media-usage' property.
3) Expect to store every
Andreas L. Delmelle wrote:
Sorry for the long post... Just trying to put a few ideas together.
Alt-design (trying the hyphen for a while) takes different approaches at
different times. While building the subtree of any node, all of the
properties are maintained in a HashMap, along with a BitSet
On Tue, 2004-01-13 at 20:49, Glen Mazza wrote:
> Let's not get too certain of anything right now with
> respect to implementation--but you probably have a
> point--a huge and very repetitively formatted document
> (say, the Chicago phone book, perhaps) would have
> comparatively fewer properties wi
Let's not get too certain of anything right now with
respect to implementation--but you probably have a
point--a huge and very repetitively formatted document
(say, the Chicago phone book, perhaps) would have
comparatively fewer properties with a higher
cardinality for each.
Glen
--- "Andreas L.
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> OK--this may also be overkill then. Thank you for the
> analysis.
>
It will prove useful, I am sure --provided we want to uphold the intention
to be able to process any size of document (from sources that may not be as
OK--this may also be overkill then. Thank you for the
analysis.
Glen
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> [Glen Mazza]
>
> > This sounds like it could be an excellent idea--a
> > PropertyRepository (extending, of course, a
> > DelmelleRepository (tm) ;) ) could be a very
> useful
> > tool
[Glen Mazza]
This sounds like it could be an excellent idea--a
PropertyRepository (extending, of course, a
DelmelleRepository (tm) ;) ) could be a very useful
tool for FO Tree Building. Prior to creating any
Property instance for any FO's array, we send the
specs of the needed property to the
Pro
Sorry for the long post... Just trying to put a few ideas together.
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
> Pardon me for repeating what might be obvious,
Well, it wasn't to me, so... thanks in advance
> but I'll like to take
> a look at what information we want to store at each FObj.
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> What I'm very concerned about, for example, are
> cases like tables, where it
> would be quite awkward to have the TableCell FObj's
> reference their own copy
> of a Property instance
To put it more precisely, the individual Properties of
an F
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > 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.
>
> Right, th
Finn Bock wrote:
[Glen]
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 w
[Glen]
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
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> 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,
--- "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 storag
> -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.
>
> > OTOH, the inherited p
[Glen Mazza]
... what's your opinion on switching to FO
Constants at this time? They probably will not give
us the rate of return that property constants have;
but there may be future indexing or processing
advantages with them. I'm not strong one way or the
other on them.
Since then, you have r
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > 1.) For the new PropertyList constructor (in the
> patch), you appear to be
> > duplicating the element ID argument, once as "el",
> the other time
> > as "elementId"--just to confirm, they are
> referring to the same thing (and
> > hence one of them
[Glen in bugzilla]
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480
I'm now looking at the changes to PropertySets.java (already applied) and
PropertyList.java (only partly so) and have a few questions:
1.) For the new PropertyList constructor (in the patch), you appear to be
duplicatin
21 matches
Mail list logo
