Noise, forwarding technical portions of an offline conversation that outgrew itself:
--- Matt Benson <[EMAIL PROTECTED]> wrote: > Date: Fri, 14 Dec 2007 10:30:20 -0800 (PST) > From: Matt Benson <[EMAIL PROTECTED]> > Subject: RE: jxpath > To: Michele Vivoda <[EMAIL PROTECTED]> > --- Michele Vivoda <[EMAIL PROTECTED]> > wrote: > > I am using jxpath on objects similiar to maps, > > coming from xml, without namespaces in the > instances > > but with an associated schema. > > I recently upgraded jxpath and made a test suite. > > > > The questions and observations I have: > > > > 1) I noticed the built -in functions that return a > > node set (keys()+?) actually return a > > NodeSetContext, > > I was wondering if this is related to the issue of > > count(). > > It probably does relate, but the manual says that > custom functions can return a nodeset, and there are > tests for it, so I think fixing count was the right > thing to do. > > > 2) when the result of a xpath is actually a call > to > > a custom function, and we are in > select-single-value > > mode, > > the whole node-set (or collection) is returned, > not > > only the first item. Ideally the function could > know > > it to be more performant, > > but this is an extra. Now I noticed that if you > > return a NodeSetContext, than it behaves as > > expected. > > This is probably a bug. > > > 3) Seen point 1 and 2, I am thinking that perhaps > > the best way is to wrap the NodeSet returned by a > > custom function > > with a NodeSetContext ? Internally in > > ExtensionFunction class I mean. > > You may be right. EDIT: I decided this was indeed the case, and reopened JXPATH-108. > > > 4) +1 is not a valid number for jxpath ? > > This appears to be correct from the spec: > http://www.w3.org/TR/xpath#function-number > > > 5) I also noticed the cache issues in > BasicNodeSet, > > I don't know if I agreee with the synchronization > > changes you made, > > is thread-safeness needed ? perhaps the class > should > > be refactored in a NodeSetBuilder, that has only > add > > and remove and then > > builds an immutable NodeSet. I have seen in code > > this is the way it is used, as an 'accumulator'. > > Otherwise , if this change breaks compatibility, > the > > class should report in documentation that it can > be > > used to accumulate and then > > can be released but it should not be modified > > afterwards. I don't know if this is feasible > > considering values that are _updated_ > > by jxpath. > > > > I am personally a proponent of proper > synchronization > in Java classes for "correct" object behavior. I am > always open to scaling back the scope of > synchronized > code for best performance, but in the common case of > making a comparison, then returning a cached value I > don't think what I did is likely to be harmful. If > however you or anyone else were to submit a patch > with > some alternate (I assume more complex) mechanism, > with > a demonstrable and hopefully corresponding increase > in > performance that would surely be reasonable, and > would > be evaluated on its merits. > Thanks, > Matt ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
