Re: [Fwd: Re: [search-ws] Description Language]

[Rob Sanderson <azaroth@liverpool.ac.uk>]

On Wed, 2008-02-13 at 13:30 +0000, Ashley Sanders wrote:

> > 4.  Inconsistency between <var name="numberOfItems"> and <items> ?
> I'm not sure I see the inconsistency.

Then I'm not sure I see what <items> means?  :)

To me it looks like it's the location in the response where the matched
items are found:

<var name="items">
  <xpath select="//mods"/>
</var>

Which is the same as numberOfItems -- the location in the response where
the number of items is found.


> >     Prefer <field type="numberOfItems">
> Now the <field> has been changed to <param> I could use
> <field> instead of <var>... However, I think I still prefer
> <var> -- pretty much as I do see them as variables in a
> programming language.

Whatever the element is called, it should be consistent with what is
described in the core model. I don't recall what they are there (I don't
think it's variables), but it should be the same in order to reduce
confusion with different names for the same thing.


> The <op> is there because you often need multiple http requests to
> achieve ones goal. I guess you could do away with <op> but I think
> it is nice to tie the request and response together inside a single
> element.

Yep.


> I still think we need to add conditions -- so that you can specify
> that an operation only occurs if a specific condition is met.
> The use case for this would be sorting a Copac result set.
> Copac only allows sort operation on result sets of less than
> a certain number of records.

I think it's going to be hard to come up with an encompassing vocabulary
to describe conditions like that.
Having a broader rather than deeper language seems more important to me
at this stage (eg cover more sites less completely, than less sites more
accurately)


> We also need to add iteration somehow. The use case for this would
> be to retrieve, say, the first 100 results from Google. Ie you need
> to request the "next page" 9 times.

Don't we get that for free from the paging parameters?

If you know where to put itemPosition in the URL/request, then you know
how to page through results.


> I also think pre- and post-conditions on operations would be good. Or in
> other words, stop all processing now if this condition is not met
> (probably because of an error or an unexpected result.)

Yep.  Some way of recognising (if not necessarily understanding) error
conditions is important.

Rob