From: <ba...@dc...> - 2003-02-20 09:00:53
|
I'm sorry, i resend this message to the list. > Correct me if I'm wrong, but getting the author alone should be easy: > > /notices/notice[.//sencence &= 'house']/author > Yes. This query is easy. > I thus assume you're trying to retrieve both, notice and author. More exactly, i am trying to retrieve sencence and author, that is, for each sencence that has the word "house", to obtain the author of the notice of this sencence (a bit different). > That requires > two queries: First, select the corresponding notices > > //notice[.//sencence &= 'house'] > > and second, retrieve the author using a nested query (see my previous message > to the list). mmm, i think it is not the same. The problem here is that with //notice[.//sencence &= 'house'] we have notices that have a sencence with 'house', but we have all the other sencences of the notice as well (not only ones that have 'house'). But in any case, maybe with nested query the problem could be solved. Do you understand? The base problem is that XPath returns always a node set, and cannot return a modified node set, that is, in the example, it could be easy to obtain what i have said if we could return the notices that have sencences with word 'house', but these notices would include ONLY the sencences with the word 'house' and not the others. Ok. I think this is a complex issue (another extension for XPath :), and not an easy extension), but a workaround would be to return the same number of authors than sentences, and then we could be to know which author corresponds to each sencence. So, something like: /notices/notice//sencence[. &= 'house']../../author could return the same number of authors than sencences with word 'house' (i'm not sure, but i will test it), and we could show sencences and authors together. :) Excuse me for my philosophical explanation. I will think about it and test alternatives. > Unfortunately, querying the exist:id attribute is not possible. > This is not a real attribute but just an internal identifier. Yes, i know. > However, I > think it would be handy to have an xpath extension function to query for the > id. I guess I will try to add one to the parser. This extension could be very interesting, although I think XMLDB doesn't include this kind of query up to date. Thank you, Mario Barcala |
From: <ba...@dc...> - 2003-02-20 14:37:12
|
> In short, eXist, in the best traditions of application design and Open > Source, uses existing (sorry!) tools to create a new tool that allows us to > do desirable but previously impossible things. But it is itself just a tool > among others, and not every tool has or should have aspirations to become a > Swiss Army Knife. Indeed many other once trim and lean tools have become > bloated and obese as a result of such ambitions. I would like to see > Wolfgang expand the implementation of XPath to incorporate more of the spec, > especially ability to use all axes, but I for one wouldn't be too keen to > encourage him to take extension any further. In my view, it's enough to give > us ready integration between eXist and other tools also at our disposal. My intention was not to be keen, it was only a thought for helping (if possible). I have been trying to find out if there was an alternative to do the query. I think eXist is a very good XML indexer, and i will try to use it to build our search system. My task is to find out if we can build it with eXist+xalan+etc and to help if possible, not to encourage to make extensions. Best regards, Mario Barcala |
From: Wolfgang M. <me...@if...> - 2003-02-20 16:25:14
|
Hi, another possibility would be to retrieve the DOM node for the matching=20 sentence (by calling getContentAsDOM on the resource) and manually traver= se=20 the tree bottom-up to find the author. Alternatively, you may walk up the= =20 tree to find the correct ancestor and transform the whole entry with XSL = to=20 extract the author. But that will only work if eXist is running embedded. I added nested queries to eXist, because I tried to extract a quick summa= ry of=20 rather complex RDF metadata records. I tried to avoid loading the whole=20 record (and pass it to an XSL) just to extract author and title. Using ne= sted=20 queries is faster in this case - in many other cases, post-processing wit= h=20 XSL will probably be a better choice. However, I would be happy to do some more work on the parser to make it a= t=20 least fully compliant with XPath. But first, the XUpdate support has to b= e=20 finished and there are some more bugs waiting to be fixed :-(=20 I have also found some promising code that could be used as a starting po= int=20 to implement XQuery (a JavaCC grammar written by Howard Katz - Michael=20 already mentioned him in his last message). So if someone likes to work o= n an=20 XQuery implementation for eXist ... there's already some good material=20 available ;-) Best regards, Wolfgang On Thursday 20 February 2003 15:46, Fco. Mario Barcala Rodr=EDguez wrote: > > In short, eXist, in the best traditions of application design and Ope= n > > Source, uses existing (sorry!) tools to create a new tool that allows= us > > to do desirable but previously impossible things. But it is itself ju= st a > > tool among others, and not every tool has or should have aspirations = to > > become a Swiss Army Knife. Indeed many other once trim and lean tools > > have become bloated and obese as a result of such ambitions. I would = like > > to see Wolfgang expand the implementation of XPath to incorporate mor= e of > > the spec, especially ability to use all axes, but I for one wouldn't = be > > too keen to encourage him to take extension any further. In my view, = it's > > enough to give us ready integration between eXist and other tools als= o at > > our disposal. |
From: Jon W. <jo...@sh...> - 2003-02-20 18:33:39
|
i have more info on my problem that should actually help. my getall.xsp file runs the following query: <xmldb:xpath> "collection('db/"+ request.getParameter("name") +"', false)" </xmldb:xpath> If I change false to true (to include sub-collections), the recently modified doc's contents actually show up when the page hits: <xmldb:get-xml as="xml"/> I get nothing with false. completely bizzare. I just don't understand. This is a bug, right? :j |
From: jon w. <jo...@sh...> - 2003-02-21 03:02:21
|
well, it's "fixed"... I have to manually kill the session at the end of my query/modify xsp page in order to get a proper query thereafter. I'm using <xsp-session:invalidate /> and it seems to work fine. I'd imagine this has something to do with exist's logicsheet storing query results in the session. But I'll leave that to Wolfgang. thank you all, you've been more helpful than you might think... :j ----- Original Message ----- From: "Jon Williams" <jo...@sh...> To: <exi...@li...> Sent: Thursday, February 20, 2003 1:39 PM Subject: Re: [Exist-open] query modify and re-store > i have more info on my problem that should actually help. > > my getall.xsp file runs the following query: > > <xmldb:xpath> > "collection('db/"+ request.getParameter("name") +"', false)" > </xmldb:xpath> > > If I change false to true (to include sub-collections), > the recently modified doc's contents actually show up when the page > hits: > > <xmldb:get-xml as="xml"/> > > I get nothing with false. completely bizzare. I just don't understand. > > This is a bug, right? > > :j |
From: Wolfgang M. <me...@if...> - 2003-02-21 16:34:43
|
Hi, > I have to manually kill the session at the end of my > query/modify xsp page in order to get a proper query thereafter. > > I'm using > <xsp-session:invalidate /> > and it seems to work fine. > > I'd imagine this has something to do with exist's logicsheet > storing query results in the session. But I'll leave that to Wolfgang. That's correct. The stored query result is just a snapshot and will not b= e=20 updated on document changes. I already started to rewrite parts of the=20 logicsheet (see xmldb2.xsl in src/org/exist) and added a cache=3D"true|fa= lse"=20 attribute to the execute element. Best regards, Wolfgang |
From: <ba...@dc...> - 2003-02-21 10:37:10
|
> another possibility would be to retrieve the DOM node for the matching > sentence (by calling getContentAsDOM on the resource) and manually traverse > the tree bottom-up to find the author. mmm, interesting. I didn't know the existence of getContentAsDOM. I was searching on eXist web, and i didn't find anything (including API JavaDoc). Is there any information about DOM related functions? Thanks, Mario Barcala |
From: <ba...@dc...> - 2003-02-20 09:25:46
|
mmm, finally what you suggest: notices/notice[.//sencence &= 'house']/author is the same as i suggest: /notices/notice//sencence[. &= 'house']../../author and it doesn't return the same number of authors than sencences, so we don't know which author corrsponds to each sentence. I think the solution is what you have said, a nested query. You get all notices that contains sencences with the word 'house', and for each notice, you query for the sencences. Then you can compound the result. The problem with this solution is that if you have an additional level in the tree, for example, the first level tag is newspaper, and this newspaper has a publication year, and you want to show this year together with the sencences, you have to make three loops: 1) Get the newspapers that have sentences that contain the word 'house'. 2) For each newspaper, get the notices that have sentences that contain the word 'house'. 3) For each notice, get the sencences that contain the word 'house'. And finally, we can compound the result. But i don't see any other solution. Mario Barcala |
From: Michael B. <mbn...@mb...> - 2003-02-20 12:01:17
|
> mmm, finally what you suggest: > > notices/notice[.//sencence &= 'house']/author > > is the same as i suggest: > > /notices/notice//sencence[. &= 'house']../../author > > and it doesn't return the same number of authors than sencences, so we > don't know which author corrsponds to each sentence. > > I think the solution is what you have said, a nested query. You get all > notices that contains sencences with the word 'house', and for each notice, > you query for the sencences. Then you can compound the result. > > The problem with this solution is that if you have an additional level in > the tree, for example, the first level tag is newspaper, and this newspaper > has a publication year, and you want to show this year together with the > sencences, you have to make three loops: > > 1) Get the newspapers that have sentences that contain the word 'house'. > 2) For each newspaper, get the notices that have sentences that contain the > word 'house'. > 3) For each notice, get the sencences that contain the word 'house'. > > And finally, we can compound the result. > > But i don't see any other solution. > I think what's behind all this is a rather important fact. XPath isn't intended as a self-sufficient query language. It's a way of describing the location of any specified part of any XML document, or, a little more precisely, of specifying any set of such locations that can be described by a single complete XPath expression. As such it is a vital tool in any mechanism for querying (or manipulating) XML, but to do more than meet that basic function it has to either be extended or supplemented by other tools. As I see it, eXist works both by extension and supplementation of XPath. The XPath extensions Wolfgang has so far implemented, however, are confined (and I would say correctly so, in keeping with key principles of XML) to filling out what many regard as a serious and unjustifiable shortcoming of XPath in the current spec: standard XPath is great for navigating document structure, but pretty weak for matching text content or attribute values. Wolfgang's extensions (which, he would be the first to acknowledge, were influenced by others, Howard Katz in particular) address those weaknesses in a way that strikes me as wholly continuous with the existing spec and certainly worthy of serious consideration by the W3C for incorporation into future revisions. However, "all" they do is give the standard XPath syntax more power to specify its targets more precisely in terms of textual content. They don't attempt to extend or modify the approach XPath takes to getting to those targets. In particular, they don't alter the inability of an XPath engine to "backtrack" and start over if an expression fails near its right-hand end. This is the result of (W3C) design decisions, made for complex technical reasons which are mainly inspired by the stress in XML specification circles on relatively easy implementability. So that's where what I call "supplementing" XPath comes in. eXist offers nested queries for precisely this purpose, to prune and/or merge nodesets via repeated applications of separate Xpath expressions, and in association with Cocoon it can use XSLT pipelining, DOM methods and/or SAX filter chains to achieve the same ends. In my uses of eXist, where for reasons I won't go into here I need to minimize dependence on Java, but where my queries are structurally quite similar to those Mario wants to do, I use eXist for the "grunt work" of retrieval, then prune/merge its result sets by using the same sort of XSLT/SAX/DOM tools, but in C/C++ libraries called from Perl. I don't regard the need to do this as in any sense a limitation of eXist. It is, arguably, a limitation of XPath as currently specified, but then the implementation implications of building a significant backtracking capacity into XPath would be pretty severe, and I'm not convinced they are justified. Even when implemented and debugged, an XPath engine capable of retrieving Mario's desired result via a single expression might end up gobbling far more resources than the apparently more laborious triple iteration currently required. In short, eXist, in the best traditions of application design and Open Source, uses existing (sorry!) tools to create a new tool that allows us to do desirable but previously impossible things. But it is itself just a tool among others, and not every tool has or should have aspirations to become a Swiss Army Knife. Indeed many other once trim and lean tools have become bloated and obese as a result of such ambitions. I would like to see Wolfgang expand the implementation of XPath to incorporate more of the spec, especially ability to use all axes, but I for one wouldn't be too keen to encourage him to take extension any further. In my view, it's enough to give us ready integration between eXist and other tools also at our disposal. Michael Beddow |