1. this "closure" could allow views to be created (analogy: an SQL query is itself a table that can be queried)
2. the top level element gives a standard place to hang the documentId (aka "key")
3. each query result can be a DOM, SAX event stream, or well formed xml string that can be parsed
I also see how some of the power of a single XPath expression is "wasted" because the valid XPath expressions that return something other than an Element are not used.
Two solutions are commonly mentioned:
1. Support XQuery (and XQueryX). This gets more stable every day, and already major companies have preliminary implementations (e.g. Oracle posted one to otn.oracle.com and IBM has Xperanto). The issues here are that Xpath must be upgraded to 2.0, and joins and recursion open up endless development opportunities for combinatorial query optimization. Maybe something could be borrowed from My SQL 4?
2. Support XSLT. This is stable and is based on XPath 1.0. Although technically capable of joins and recursion and thus amenable to combinatorial optimization, this is not implemented in practice. Perhaps Xalan could be embedded in Xindice in much the same way as its Xpath subset was repurposed?
At 07:18 PM 4/5/02 -0500, you wrote:
I don't know much about the DB:XML standards or the motivations behind tying
Xindice to them, and what I'm about to say may be beating a horse you've all already
beaten--if so let me apologize ahead of time. I'm afraid I haven't had the time to
follow the Xindice query support as closely as I'd like, or these mailing-lists, but I was
fairly shocked that Xindice didn't support attribute query returns. So I just wanted to
chime in with my 2 cents on this from the stand-point of my experience using XML
databases and XPath queries to get real work done (mainly with Tamino).
Being able to do XPath queries that return just attributes is CRITICAL. I need and
use this all the time. The most basic example is also the most onerous if you're
forced to get the element and it's entire sub-tree: suppose you need a list of just the
ids of documents matching a particular your query criteria. Suppose also these
documents are fairly large, and / or the result set very large. The list of ids might
have been a 1k of data but the list of entire documents a 100 Megs. This limitation
has just rendered a very basic application task impractical.
Normally I'm all about standards and staying away from "proprietary", but
I don't rate having the result of the query in conformance to some standard very high.
If it's XML, it can always be transformed to some other format. What I do rate high is
power and flexibility. Power and flexibility in defining not only the query criteria but
also what data is returned.
Being able to get ALL of an element's attributes would also be a very useful feature
(is "@*" legal XPath syntax?) Being able get the child text nodes of an element
without all of the element's descendant elements would also be huge (if I read the
spec correctly XPath does not support this). Efficient support for unions, to
selectively retrieve a few non-contiguous portions of the xml tree would also be great
(as awkward as the Xpath union syntax may be). And personally, I'm not all that
enamoured of XML Query as a cure-all for XPath's limitations, most of which could
be solved by very simple extensions to the syntax..
I'd much rather have non-standard extensions to the current standards (even XPath
itself) to get the job done, then be limited by standards that aren't entirely baked yet.
-- Eric Schwarzenbach
On 5 Apr 2002 at 0:35, Mark J. Stang wrote:
> Everyone is correct, it doesn't work. It is not Xindice, but rather > the XML:DB or DB:XML or something like that API that doesn't support > it. So until the API is updated, Xindice doesn't support it. > HOWEVER, this is not to say that you can't get back the node that > contains the attribute. I have nodes like: > > <name first="mark" last="stang" /> > > And I do searches for "mark" or "stang" and they work, they just > return then entire node. So, you get more than you asked for. > And if you search for an attribute of the root node, then you can get > the entire document. > > Check out: > > http://www.zvon.org/xxl/XPathTutorial/General/examples.html > > I have yet to find any bugs in the XPath queries :-). > > HTH, > > Mark > > Maarten Eerdekens wrote: > > > Xindice can only return a nodeset as a result of a xpath query, and > > because attributes are no nodes, this returns nothing. You will have > > to make a work around. I think I heard the experts are working on > > it. > > > > -----Original Message----- > > From: Dominic Gamble [mailto:[EMAIL PROTECTED] > > Sent: vrijdag 5 april 2002 8:55 > > To: [email protected] > > Subject: Xindice doesn't fully support XPath? /@attribute doesn't > > work! > > > > It seems that XPath /@attribute queries don't work in Xindice! > > Please tell me I am wrong. > > > > When I execute the following xpath query: > > > > xindice xpath -c /db/websystem -q "/Classes/Class[last()]" > > > > I get the following results: > > > > <?xml version="1.0"?> > > <Class name="Page" id="1" superclass="1" template="1" > > xmlns:src="http://xml.apache.org/xindice/Query"; > > src:col="/db/websystem" src:key="class"> > > <Elements> > > <Element name="Title" class="Single Line Text" > > required="true" /> <Element name="Author" > > class="Single Line Text" required="false" /> > > <Element name="Keywords" class="Single Line Text" > > required="false" /> <Element name="Description" > > class="Single Line Text" required="false" > > /> > > </Elements> > > </Class> > > > > This is all ok, but when I then attempt to get the attribute 'id' > > only, using the following query: > > > > xindice xpath -c /db/websystem -q "/Classes/Class[last()]/@id" > > > > I get NOTHING! This happens both from the command line, _and_ from > > within code. > > > > Does anyone know why? Has it just not been implemented? > > I'm using Xindice 1.0. > > > > Thanks, > > Dominic Gamble > > Stratlink >
Cheers, Gary
