[jxpath] discussion

[Matt Benson <gu...@yahoo.com>]

Noise, forwarding technical portions of an offline
conversation that outgrew itself:

--- Matt Benson <gu...@yahoo.com> wrote:

> Date: Fri, 14 Dec 2007 10:30:20 -0800 (PST)
> From: Matt Benson <gu...@yahoo.com>
> Subject: RE: jxpath
> To: Michele Vivoda <vi...@hotmail.com>

> --- Michele Vivoda <vi...@hotmail.com>
> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org