> Date: Tue, 29 Jun 2004 12:35:11 +0100
> From: Robert Sanderson <[log in to unmask]>
>
> The only other place where we have data returned which isn't
> generated by the server as part of the protocol is <recordData>, and
> there's already a rule that says recordData must be legal XML.
Yes; this is relatively easy to deal without, without touching the
core protocol, because we can define schemas whose specification
includes a statement that the content of all elements is QP-encoded
(or whatever). There is no analogous flexibility in scan responses --
and I am inclined to think that is as it should be, contra Matthew's
proposal for solving this problem.
> The query terms can already be handled via a XXX.base64 relation
> modifier.
Yes, although we have yet to agree the precise form of this -- see
message to follow.
> Anyone writing a context set or identifier with names that include
> unserializable characters is just taking the piss [...]
Quite :-)
I checked the definitions at
http://www.loc.gov/z3950/agency/zing/cql/bnf.html
Perhaps CQL itself should be more specific about what is allowed in
identifiers? As presently written, the specification allows control
characters in index names, for example.
> [...] and the characters couldn't be transferred in a URL (?) or via
> SOAP anyway.
If this is true, it's irrelevant. We've made a big song and dance
about the fact that we are defining an abstract protocol here, and
that SOAP and HTTP GET are just two of many possible transports. So
we need to define the protocol itself in a way that does not assume
that weaknesses in one transport will necessarily be reflected in
others.
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "Been a long time, been a long time, been a long lonely lonely
lonely lonely lonely time" -- Led Zeppelin, "Rock & Roll"
--
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/
|