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
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]> http://www.miketaylor.org.uk
)_v__/\ "istrcmp() -- Naughty but nice! ... Why isn't my program
working?" -- Sunstorm the Intestinal.