Dr Robert Sanderson wrote:
>> Just when we are about it - an xpath expression on CQL ?? Something like
>> /this/that[@attribute="xyz"]=somestuff
>
>
> We can sort of already do this if the CQL parser allows for quoted,
> dynamic indexes. Equally, the value could be hacked into a relation
> modifier value with a magical index.
>
> foo.magical any/foo.xpath="/this/that[@attribute='xyz']" somestuff
I did miss the possibility of quoted, dynamic indexes. This is of course
the way to go!
>
>
> However it does not fit the abstract data model of SRW nor CQL, as we
> cannot determine several crucial things required to process the above
> query:
>
> * Schema that the server uses internally, if any
> * Schema that the XPath expression should be applied to
> * Namespaces for the XPath expression
>
I am aware of these restrictions - it is pretty clear that _if_ you want
to have the slightest chance to make xpath queries suceed, you have to
know the data model into details.
> Secondly, XPath over the wire is practically never the right solution.
>
Well, I can imagine quite a lot of system integration tasks where we at
the moment make the 'de-route' of indexing xpath expressions into bib1
attr sets, and asking in the client with CCL/CQL and a CCL/CQL parser,
just to translate the stuff into PQF @attr this=that queries.
It would be much cleaner to be able to make xpath index queries
directly, wihtout the need of translations all the time.
Off course, xpath queries are _not_ the right solution for a end user
GUI, but given the nice syntax of CQL, it's a shame not to use it for
system integration, where I have all the information needed.
> If you control the server, then you can define an index in a profile
> which
> resolves to that XPath.
Only for predefined xpath queries - not for arbitrary xpath queries
> If you don't know the data, then you can't tell
> what to use in the XPath. If the data changes, your query is suddenly
> inaccurate (eg going from one version of a schema to another) or if the
> data is heterogeneous (MODS data and MARCXML data in the same database)
>
> So the only situation in which it would be useful would be:
>
> * The server only supplies one schema, or can determine which schema to
> use from the XPath expression
> * The records do not use namespaces
> * The client knows the data and the schema
> * The data is completely homogeneous
>
> Hence there isn't an official XPath query type.
Thanks for the thoughts and input on this issue. I will investigate
'dynamic quoted' xpath indexes in future!
Marc Cromme
>
> Rob
>
> ,'/:. Dr Robert Sanderson ([log in to unmask])
> ,'-/::::. http://www.o-r-g.org/~azaroth/
> ,'--/::(@)::. Dept. of Computer Science, Room 805
> ,'---/::::::::::. University of Liverpool
> ____/:::::::::::::. L5R Shop: http://www.cardsnotwords.com/
> I L L U M I N A T I
>
--
Marc Cromme, cand. polyt, Ph.D
Senior Developer, Project Manager
Index Data Aps
Købmagergade 43, 2
1150 Copenhagen K.
Denmark
tel: +45 3341 1000
fax: +45 3341 0101
http://www.indexdata.com
INDEX DATA Means Business
for Open Source and Open Standards
|