I want to echo Ralph's request to see some programming examples (could be C
or Java or Perl) constructing a reasonably complex query in the parameter
idiom of a toolkit or two. We already know what CQL looks like in XML. What
does it look like in Java? :-)
I'm still inclined to lean somewhat towards an XML fragment, but that's
because I am a little concerned what it will be like to construct and parse
XCQL when it's been chewed over by the range of toolkits that will be
employed... some may (like GSOAP) provide easy access to the underlying
XML, but maybe not all do this. I'm not really worried about changes to
XCQL to accomodate broken/immature SOAP TKs, but I am a little concerned
about what they all do with it.
I parallel it to our own experience building toolkits at Index Data...
apart from our very first C toolkit, I think we've almost exclusively
represented queries in strings, simply because building them in programming
language structures is too much of a hassle and too hard to convey in a
series of short examples in a tutorial...
Building XCQL queries could throw hapless client developers into producing
recursively nested structures in the idioms of their SOAP tk -- something I
suspect most other search interfaces forces them to do.
Of course, this could equally well be read as an argument for dropping XCQL
entirely and going with CQL alone, but then I've always been worried that
the efforts to make CQL friendly-looking for people has rendered it clumsy
to extend, so maybe we'll outgrow THAT. I *am* an old worryer, aren't I?
--Sebastian
At 21:42 20-11-2002 +0100, Adam Dickmeiss wrote:
>On Wed, Nov 20, 2002 at 07:48:39PM +0000, Robert Sanderson wrote:
> > > me - but it seems it is to you. For example why do have a <value>
> > > inside a <boolean> inside a <triple>? Why not just <value> inside
> <triple>?
> >
> > Unless there are other people who think XML Fragment is a good idea, I'll
> > give up as I'm utterly sick of discussing it.
>If people think XML fragments makes XCQL eaiser to work with, then
>fine by me. Furthermore IF it is the case, then note that the
>rules apply to XCQL too - perhaps even some record formats.
>
>I just wanted ensure that we don't choose a different encoding for
>such a detail as a simple wrapper element. Basically, I'm happy with
>the current XCQL - and since I will never enter XCQL manually it doesn't
>matter if it's not "minimal".
>
>Considering that on Friday the latest spec was never - compiled -
>implemented - and tested in actual operation, the current
>spec is not that bad. I imagined much worse things to "pop" up.
>
>I don't know if you're proposing a completely new schema for XCQL, but I
>must say "stop": I'm happy with the current spec.
>
>-- Adam
>
> > Okay, so assuming that we put XCQL under SRW and put in the additional
> > elements, there's a load of other changes we should make too.
> >
> > I think the resulting structure is:
> >
> > <xQuery type="operandType">
> > <triple type="xcqlType">
> > <prefixMap type="Map">
> > <boolean type="booleanType>
> > <value type="string">
> > <modifierMap type="Map">
> > <left type="operandType">
> > <searchClause type="clauseType">
> > <index type="string">
> > <relation type="relationType">
> > <value type="string">
> > <modifierList type="Array" arrayType="string">
> > <modifier type="string">
> > <term type="string">
> > <right>
> > [as left]
> >
> > Where Array is SOAP-ENC:Array and Map is the Apache Map type.
> >
> > xSortKeys should be an Array of "sortKeyType"
> >
> > Same arguments for left and right apply to these changes, so there should
> > be no problem. It makes it much easier for parsing as TKs will already
> > support Apache's Map. (most of the interop test suites require it) rather
> > than making our own <prefixes> and <modifiers> which are just Arrays and
> > Maps anyway.
> >
> > Okay?
> >
> > Rob
> >
> > --
> > ,'/:. Rob Sanderson ([log in to unmask])
> > ,'-/::::. http://www.o-r-g.org/~azaroth/
> > ,'--/::(@)::. Special Collections and Archives, extension 3142
> > ,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
> > ____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
> > I L L U M I N A T I
>
>--
>Adam Dickmeiss mailto:[log in to unmask] http://www.indexdata.dk
>Index Data T: +45 33410100 Mob.: 212 212 66
--
Sebastian Hammer, Index Data <http://www.indexdata.dk/>
Ph: +45 3341 0100, Fax: +45 3341 0101
|