Re: Xindice doesn't fully support XPath? /@attribute doesn't work!

[Gary Hallmark <Ga...@oracle.com>]

I can see how Xindice needs to return a collection of Documents as the 
result of a query over a collection of Documents:
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:dominic@stratlink.com.au]
> > > Sent: vrijdag 5 april 2002 8:55
> > > To: xindice-users@xml.apache.org
> > > 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