Re: XMLDBSource XPathQueries
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]
Re: XMLDBSource XPathQueries
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. 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. 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 -- [EMAIL PROTECTED] / [EMAIL PROTECTED] "Absinthe makes the hog Jane Fonda"
Re: XMLDBSource XPathQueries
On Fri, 2004-04-23 at 15:27, Andrew Thornton wrote: > Bruno Dumon wrote: > > Maybe you could let a factory create the PointerParts, and pass the > > factory as an argument to the constructor of the parser. > > Seems like that is probably the best idea. > > > Or you could indeed move the processing out of these classes, though > > that's about the only thing they do... > > 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? > > 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? -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: XMLDBSource XPathQueries
Bruno Dumon wrote: Maybe you could let a factory create the PointerParts, and pass the factory as an argument to the constructor of the parser. Seems like that is probably the best idea. Or you could indeed move the processing out of these classes, though that's about the only thing they do... Hmm. XPaths don't process documents there's an XPathProcessor for that. Similarly is it correct the XPointers process Contexts? 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? Thanks, andy -- [EMAIL PROTECTED] / [EMAIL PROTECTED] "Absinthe makes the hog Jane Fonda"
Re: XMLDBSource XPathQueries
On Fri, 2004-04-23 at 11:06, Andrew Thornton wrote: > > > href="test2.xml#xmlns(my=http://localhost/my)xpointer(/page/content/my:abc/*)"/> > > > > > > > > If you to implement a patch allowing to do: > > > > > > xindice:///db/collection/resource#xmlns(my=http://localhost/my)xpointer(/page/content/my:abc/*) > > > > > > > > Then I'd happily apply it. Under one condition: old URIs without > > namespaces / xpointers should still work. > > OK. I'm currently trying to use the XPointerFramework that is used by > the XIncludeTransformer, mainly because I don't think it would be > correct to rewrite a parser. the parser's quite small actually > However the framework is very tied to the > idea of processing on the cocoon side whereas I need the processing to > be done by the XMLDB. I'm trying to spoof the required behaviour but I'm > not sure I should be doing this. > > What do people think? Should I fix the XPointerFramework so that the > XPointerParts returned by the Parser do not the processing? Maybe you could let a factory create the PointerParts, and pass the factory as an argument to the constructor of the parser. Then you make your own factory which returns your own PointerPart implementations (which wouldn't even need to implement the PointerPart interface). Or you could indeed move the processing out of these classes, though that's about the only thing they do... > Should I > reimplement the framework for the XMLDBSource? Or should I carry on with > my spoofing attempt? > > My spoofing idea was to the hack together a context, manager and > processor and make them interact with the database transparently to the > Framework. In that when the context has prefixes added it sends them to > the XPathQueryService of the XMLDB, and when the XPointerPart calls the > XPathProcessor, it actually speaks to the database returning the obvious > parts. (A similar idea was to get the XPathProcessor to throw an > exception/or just to return null, and then I could ask the processor > what the XPointer wanted.) > > Any ideas? > > Thanks, > andy -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: XMLDBSource XPathQueries
http://localhost/my)xpointer(/page/content/my:abc/*)"/> If you to implement a patch allowing to do: xindice:///db/collection/resource#xmlns(my=http://localhost/my)xpointer(/page/content/my:abc/*) Then I'd happily apply it. Under one condition: old URIs without namespaces / xpointers should still work. OK. I'm currently trying to use the XPointerFramework that is used by the XIncludeTransformer, mainly because I don't think it would be correct to rewrite a parser. However the framework is very tied to the idea of processing on the cocoon side whereas I need the processing to be done by the XMLDB. I'm trying to spoof the required behaviour but I'm not sure I should be doing this. What do people think? Should I fix the XPointerFramework so that the XPointerParts returned by the Parser do not the processing? Should I reimplement the framework for the XMLDBSource? Or should I carry on with my spoofing attempt? My spoofing idea was to the hack together a context, manager and processor and make them interact with the database transparently to the Framework. In that when the context has prefixes added it sends them to the XPathQueryService of the XMLDB, and when the XPointerPart calls the XPathProcessor, it actually speaks to the database returning the obvious parts. (A similar idea was to get the XPathProcessor to throw an exception/or just to return null, and then I could ask the processor what the XPointer wanted.) Any ideas? Thanks, andy -- [EMAIL PROTECTED] / [EMAIL PROTECTED] "Absinthe makes the hog Jane Fonda"
Re: XMLDBSource XPathQueries
Vadim Gritsenko wrote: I don't like this much also. Why don't you suggest the syntax which is already used for xinclude transformer? See examples: http://localhost/my)xpointer(/page/content/my:abc/*)"/> Oops, didn't see that! Sorry... (We're mostly a cinclude shop.) If you to implement a patch allowing to do: OK. I'll have a hack. Then I'd happily apply it. Under one condition: old URIs without namespaces / xpointers should still work. Of course. Thanks, andy -- [EMAIL PROTECTED] / [EMAIL PROTECTED] "Absinthe makes the hog Jane Fonda"
Re: XMLDBSource XPathQueries
Andrew Thornton wrote: Hi! I'm currently trying to use the xmldb source. However I've spotted a problem. The source doesn't currently handle xpaths with namespaces. We have a few suggestions for how to make it do this: ... xmldb:xindice-embed:/xmlns(x=http://apache.org/cocoon/xmldb/1.0)xmlns(ns=NAMESPACE-URI)x:collection(/db/collection/collection)x:resource(resource)xpointer(ns:xpath[predicate()]) Total Overkill, me thinks. (ii) Leverage the xpointer idea only for namespaces: xmldb:xindice-embed:///db/collection/collection/resource#/ns:xpath[predicate()] becomes xmldb:xindice-embed:/xmlns(ns=NAMESPACE-URI)xmlns(other=OTHER)//db/collection/collection/resource#ns:xpath[predicate()] I don't like this much also. Why don't you suggest the syntax which is already used for xinclude transformer? See examples: http://localhost/my)xpointer(/page/content/my:abc/*)"/> If you to implement a patch allowing to do: xindice:///db/collection/resource#xmlns(my=http://localhost/my)xpointer(/page/content/my:abc/*) Then I'd happily apply it. Under one condition: old URIs without namespaces / xpointers should still work. Vadim
