Ray Denenberg, Library of Congress writes:
 > A report covering the June 18 meeting (SRU implementor/Ed. Board
 > meeting) is available at:

Thanks, Ray -- and thanks to whoever put together this very
comprehensive report.  Most of that looks pretty good to me.

... with the exception of this brain-damage: "It was the consensus of
the meeting that there should be a parameter (in SRU version 2.0) to
specify the requested response schema: SRU, RSS, ATOM, ext."

But luckily for everyone who agreed with this idea at the meeting, I
am too tired to fight it.

One small comment:

> Note that this approach, prox/xyz.unit="street", is preferable to
> 'Prox/unit=xyz.street'. In the first case, 'unit' is a modifier
> define in the xyz context set, and 'street' is a value defined for
> that modifier. In the second, 'unit' is a modifier from the cql
> context set, with a value defined in a different set. so it's value
> would have to be one that is defined in the cql context set. Pairing
> a modifier from one set with a value from another is not a good
> practice.

It's not just "not good practice", it's impossible.  Context sets do
not contain relation-modifier values at all, just relation-modifier
types.  In other words, CQL implementations may parse relation
modifiers (as they do with indexes) to isolate the prefix and map it
to a URI, but they treat modifier values as opaque strings.

> Review use of terms "Explain" and "Zeerex"in the 1.2 spec.

I'm sure you got this at the meeting, but: Explain is a service,
ZeeRex is a format.  They are analogous, respectively, to HTTP and

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor    <[log in to unmask]>
)_v__/\  "istrcmp() -- Naughty but nice! ...  Why isn't my program
	 working?" -- Sunstorm the Intestinal.