[Koha-bugs] [Bug 11297] Add support for custom PQF attributes for Z39.50 server searches.

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11297

--- Comment #15 from David Cook <dcook at prosentient.com.au> ---
(In reply to Blou from comment #13)
> Actually, I said that because the old patch (which was waaay impossible to
> apply anymore) would have replaced one 4= by another.  In this new patch,
> Maxime prepends the 4=1 to whatever is there by default (4=109, let say), so
> I figure both are sent.
> 
> small characters: But I might be wrong. :)

I just took a look at the patch, and that sounds...interesting. I'd have to do
more research, but http://www.loc.gov/z3950/agency/defns/bib1.html recommends
not repeating attribute types in an attribute list. I imagine server behaviour
might vary here as well... I imagine some servers might use the first value (so
4=1 even though 4=109 comes later), or might return an error, or do some other
behaviour. 

I think what Jonathan was saying is that there's no way to provide 4=1 and
4=109 in a single query. For instance:

@and @attr 1=4 @attr 4=1 "The cat in the hat" @attr 1=12 @attr 4=109
"123456789"

The patch would only allow the following:

@attr 4=1 @and @attr 1=4 "The cat in the hat" @attr 1=12 "123456789"

Which effectively is the same as 

@and @attr 1=4 @attr 4=1 "The cat in the hat" @attr 1=12 @attr 4=1 "123456789"

--

This could cause a problem if "123456789" isn't stored in a phrase index but is
instead stored in a numeric index. 

That being said, Zebra's default structure attribute is phrase
(4=1)(http://www.indexdata.com/zebra/doc/querymodel-rpn.html). 

But the default structure attribute can range from server to server... so I
don't think it would be wise to add default structure attributes for all
servers...

--

After some musing, I think that I'm OK with this patch. Overall, I don't like
it. I rather given control of the structure to the user doing the Z39.50
search.

However, since the user is only inputting the terms and we currently control
everything else about the PQF query formation, perhaps it doesn't hurt to allow
us to provide values that apply to the whole query.

That being said, I think this attribute field needs a validator. Only valid PQF
should be allowed in this field, and of that PQF, USE attributes should never
ever be allowed. 

I'm skeptical about other attribute types being allowed as well, but I suppose
they may be necessary in the event that a Z39.50 target doesn't have default
values... 

--

I also think tests should be done to see what happens when you provide a
structure attribute at the query level and what happens when you provide a
different one at the term level... in case we want to change the structure
attribute for specific fields in the future...

Anyway, that's my 2 cents ;)

-- 
You are receiving this mail because:
You are watching all bug changes.