On Fri, 2004-04-23 at 18:16, Andrew Thornton wrote: > Bruno Dumon wrote: > > On Fri, 2004-04-23 at 15:27, Andrew Thornton wrote: > >>Hmm. XPaths don't process documents there's an XPathProcessor for that. > >>Similarly is it correct the XPointers process Contexts? > > > > > > Not sure what you mean with the word "XPaths" here. Are you referring to > > a class or to XPath expressions themselves? > > I meant the Xpath expressions. Just thinking aloud. Maybe the classes > are misnamed, they're really XPointerProcessors.
in a sense, yes, though I don't think they're really misnamed. The XPointer class represents a parsed XPointer and has behaviour for evaluating that XPointer. > > >>That being said, I think the XmlnsPart.process() does do the right > >>thing. It sets the namespaces on the Context. Maybe the XPointerPart is > >>trying to do too much. Perhaps the XPointerPart should simply do the > >>XPath with respect to the Context, and not stream? > > > > And what alternative do you propose? > > > > I don't think that the XPointerPart.process() should stream the result. > It should XPointerContext.setXPointerResult(NodeList) or return the > NodeList. Ah, here lies the problem: the reason the pointerparts directly stream the results is to allow streaming behaviour, i.e. they should not be obliged to create a DOM tree but allow streaming processing. > That way it is up to the original caller to do what it wants > with the result, and the XPointer.process() behaves more like the > XPathProcessor. > > I think wrapping the XMLDB api stuff in an XPathProcessor and > XPointerContext is probably the right thing to do. After all I am trying > to leverage a Cocoon/Avalon API, I should make the XMLDB API behave in > that world. > > Thanks, > andy -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
