Re: The imprecision of Z39.50

> In fact, we very deliberately did _not_ consider how various
> attributes might be implemented.  The prevailing feeling was that the
> AA should be, if you like, declarative rather than procedural -- it
> should say _what_ is to be done without consideration of _how_.  So
> that's why it doesn't fit the approach you're trying to take here.
> (Whether that was the right approach or not, I will not try to argue
> :-)

First, a minor nit. Defining a model does not make it procedural.
A complaint I have with the AA *specification* as it is written is
that there is an *implicit* model, but I suspect the model assumed
by descriptions of different attributes is different. If the model
was explicit I think these issues would have been spotted. I think
the correct way to express your line of argument is to say it was
intended to keep things open to allow people to implement it in
different ways. But I think its important for a standard to be
unambiguous and clear to promote interoperability. If a human can
not work out what a query means in their head, then there is a problem.
(Ok, so the problem may be with the human...)

More centrally, I have two questions/observations.

(1) Should the attribute archtecture try to fit it with the overall
    protocol (including things like scan - sort also can use attributes)
    or only worry about queries? Scan uses attributes too, so I think
    the AA should deal with scan.

(2) Ignoring the model I put up, I cannot work out how the AA supports
    querying on title as a complete value and title as words in a reliable
    way. It seems like you have to look for about 10 magic combinations
    of attributes to work out which form to use. And I cannot work out
    these combinations from reading the spec. This is not a question of
    implementation, this is purely a question of interpretation of a query.
    The individual attributes are one thing, but the combination of
    them that gets into deep water pretty quickly. The draft Bath profile
    for Bib-2 is a good example. It had one complete value based query I
    reported previously that I think should be interpreted as a word based
    query (but got not resolution on this when I asked).

I think scanning and word/complete value is the one to focus on. If
its addressed, then everything else will fall out in the wash I suspect.
Or do people think the AA should not deal with scan?

In terms of adoption, I have been trying to use the new AA on some
projects, but have been unable to because I have found it impossible
given an arbitrary attribute list to work out its interpretation (I am
not talking about how to implement - purely what does the query mean),
and given some common queries I have found it impossible to work out the
attribute list. I could not recommend any of our customers to use the AA.

Alan

ps: Regarding SQL, I was referring to the core standard, not all the
add-ons different vendors have added. If I write the query

    SELECT * FROM Employees WHERE Name = 'Mike Taylor'

I know what I will and wont get. This is not true for SQL. But I certainly
appreciate what you mean when you talk about the differences between SQL
engines. I think more that it is *possible* to write queries where they
will do the same thing on all installations.

Received on Thursday, 3 July 2003 18:58:51 UTC