> > done there; but people will also use SRW to fetch summary records from
> > 40Mb EAD records.  I think an eSpec-alike is indispensible for
> > building a Real IR protocol (as opposed to something for people to do
> > web-searches with.)

> But do we really need a full blown eSpec or just brief and full EAD
> record specs? (I have a feeling you're going to say yes ;-)  ). Will we

It's not just EAD though.  There's no restriction in SRW that you can't
use it for only short metadata records... Imagine someone with (say) full
text journal articles.  Or full texts of entire books.  Or SVG even?
Search through complex structures and return instances of circles. (or
whatever SVG primitives are like)

So for each application multiplied by each base xml schema you'd need a
new schema to say what you wanted back. Or you require the client to do it
all having received back a bazillion megabytes of data, or you just use
XPath at the server... the server that is supposed to know its own data.

> A full EAD record is almost a database in its own right, so perhaps you
> want to search with a finer granularity as to the level of the record
> you want back rather than do eSpec/qSpec things? And yes, I can remember
> all the discussions which eventually lead to qSpec at the 98 ZIG.

That's another question, certainly, but the current one remains and
applies to non EAD-like structures as well.  You wouldn't expect a book to
be broken down arbitrarily into paragraphs just to make it easier to
return them individually...

> Yep - that was my point, you throw in an full Xpath implementation off
> the shelf rather than do a complex hand-coded lookup table and this
> comes with lots of clever Xpath extensions in which you hacker manages
> to exploit to get into your server...

I just don't buy it.  Are there any examples anywhere of an exploit
written in XPath? And if there isn't, why are we concerned?  If there is,
and the server writer just included an off the shelf product, then that
makes it the product maker's responsability to fix, in all likelihood.  Or
at least provide an option saying 'Don't accept any functions other than
[list of simple functions]'


      ,'/:.          Rob Sanderson ([log in to unmask])
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Nebmedes:  telnet: 7777
____/:::::::::::::.                WWW: