[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 #16 from David Cook <dcook at prosentient.com.au> ---
tl;dr

In summary, if this patch is to pass QA, I think the attributes field needs to
be validated to only contain PQF attributes, to contain no USE attributes, and
to include no duplicated attribute types.

As per http://www.loc.gov/z3950/agency/defns/bib1.html, an attribute type
should only appear once in an attribute list. (There is a mention that you can
repeat attribute types if you provide semantic guidance but I don't see a way
of doing that within the constraints of the PQF grammar:
http://www.indexdata.com/yaz/doc/tools.html#PQF.)

This means that Blou's mention of 4=1 4=109 is not in accordance with the spec.

However, it seems to me that you can provide 4=1 at the query level and 4=109
at the term level in a query, since they belong to separate attribute lists. If
you look at http://www.indexdata.com/zebra/doc/querymodel-rpn.html, it states
that:

"Any of the orthogonal attribute types may be omitted, these are inherited from
higher query tree nodes, or if not inherited, are set to the default Zebra
configuration values."

To me, that sounds like you could provide 4=1 as a query level default
structure attribute, and then provide a more specific structure attribute at
the term level (e.g. 4=109) which will be used instead of 4=1 as it's more
specific. If other terms don't have a more specific attribute, they'll inherit
from the query level, or from the servers default, if there is one.

Anyway, going back to whether or not this patch is suitable in Koha...


I re-read the Bib-1 Set docs from the Library of Congress
(http://www.loc.gov/z3950/agency/defns/bib1.html), and stumbled upon an
important passage:

"If an attribute type does not occur in an attribute list, then (in the absence
of any prior understanding, either outside of the standard or via the Explain
facility) the origin should not expect any particular default target behavior."

This led me to another passage at http://www.loc.gov/z3950/agency/bib1.html:

"Within an attribute list, each attribute type is optional.  However, if
a particular attribute type is not supplied, this document does not
address target behavior -- a given target might supply a default
attribute, dynamically select an appropriate attribute based on the
other attributes supplied, or fail the search because it requires that
the attribute type be supplied."

Based on these passages, I think it is imperative that we provide some
capability for providing default attributes to a query. Providing them at the
query level rather than at the term level is perhaps the most sensible. 

Ultimately... I've changed my mind and I'm now in favour of this feature... but
I think is needs to be validate the attributes that the user is providing.

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