On Wed, Nov 20, 2002 at 02:35:01PM +0000, Robert Sanderson wrote:
>
> > Rob is absolutely right! I'm particularly persuaded by the argument that
> > the SRW server builder will have to use a parser tool to parse CQL, so s/he
> > might as well use the same tool to parse the XCQL. Otherwise, s/he's going
> > to need two different query evaluation tools. As a client builder, I don't
> > look forward to making the series of nested structures necessary to emit the
> > correct XCQL. It seems to me that it will be much easier to hand-forge the
> > XCQL query.
>
> I don't know if I made that argument, but it looks like a good one :)
>
> Mostly I'm particularly concerned about the precedent. My bounced message
> from last night boiled down to:
>
> (1) If we do it now, we'll probably have do it again the next time CQL
> changes. Which will make all of version 1.0 servers and clients not
> interoperable at all because the structure won't conform.
> As people are interested in CQL (cf Mike) this is likely to happen.
Wrong. CQL will not change of because of XCQL (not with my permission).
You seem to confuse semantics with grammar(looks) (again).
> (2) Next time the Choice in Sequence issue comes up again, we have to add
> even more elements. This is just dishonest to say that CQL isn't dependant
> on SRW, as the design choices are made such that it can be part of the SRW
> SOAP structure. I think that CQL and SRW as different projects is a good
> idea, so don't want to go back to this.
If you make XCQL defined externally and transported as an
arbitrary structure, I wonder why we have XCQL at all.
SRU doesn't support it, SRW tools doesn't support it too - if you
omit the elements for which you admitted there was no _technical_ reason
for not having.
-- Adam
> > Matthew is absolutely right! One of the main arguments for starting this
> > whole process was that we wanted the application programmers to use standard
> > tools and few of them. The whole idea behind using SOAP (beside it being
> > the "Good Idea"(tm) of the month) was the hope that a standard SOAP toolkit
> > would be the only toolkit needed.
>
> Yes. I agree. Though I think any half sensible client will have at
> least an XSLT transformation engine to do things with the records, and
> probably will want to have an XML library to do DOM like stuff.
>
> Though in support (!?) of left and right, I think I would need
> them too as ZSI's typecoding for choice requires it to be named.
> [That said, I would just route around the problem and add a new type for
> them to parse into, solving the problem without messing with the XCQL.]
>
> > that the best technical solution is often not the best solution. I have a
> > slight preference for the hand-crafted XML solution.
>
> So currently:
>
> XML Fragment: Rob, Mike and a slight preference from Ralph
> XCQL changes: Matthew, Adam
>
>
> > Success Story:
>
> Very cool :)
>
> I've got a super experimental server at:
> http://www.o-r-g.org:8080/
>
> It doesn't do DC at all yet, and ignores recordSchema.
>
> Indexes:
> text:
> cardname, cardtext, anywhere, cardtype, artist, keyword
> numeric:
> force, chi, experience, focus, gold, honour
>
> Also, super simple client:
> http://liverpool.o-r-g.org:8000/code/list?object=2&verb=9
>
>
> 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
|