On Tue, 29 Jun 2004, Mike Taylor wrote:
>> From: "Matthew J. Dovey" <[log in to unmask]>
>>> Regarding Rob's actual question, the correct answer is and
>>> must be that XML is just a broken transport.
>> Which is probably why it has been fixed in XML 1.1 (remember how we
>> fixed some stuff when we moved from SRW 1.0 to 1.1?)
> Yes. That is nice for the maybe four or five XML 1.1 applications out
>> A) XML 1.1. already fixes this - XML 1.1 is currently in a final
>> draft so it may be 6 months or so before it becomes part of the Web
>> Services stack but any fix we make now will be rendered obsolete
>> when XML 1.1 is supported.
> Give it six _years_ and you may be right.
I have to agree with Mike here. Waiting for XML 1.1 to become widely
adopted isn't a real solution and would probably require moving to SRW1.2
anyway... But we shouldn't fix things in such a huge way as Mike's
original suggestion which would take until XML 1.1 was widely supported to
be implemented as it would definitely require moving to 1.2
>>> HOWEVER, we clearly also need to be able to send
>>> base64-encoding CQL queries,
>> Well no - we just need a relational modifier to indicate that the
>> *term* is base64 encoded (which we need anyway for sending binary
> Yes, this is a better approach one as it solves the problem for other
> CQL applications as well as SRW. I have only two comments: first,
> that the relation modifier's name "mimeEncoded" is ambiguous as it
> could refer either to Base64 or Quoted-Printable, and second that this
> is useful and general enough to belong in the base CQL context set
> rather than an application-specific one.
This was discussed at the meeting in DC with regard to getting rid of
XCQL -- that anything which could be expressed in xcql could be done with
a string encoded term. So I'm somewhat surprised that it isn't in the cql
I think that cql.base64 is required outside of any binary scan term
>> B) having control characters in the scan seems to me to be such a
>> pathological (albeit real) case, that taking such a radical knife to
>> SRW seems out of proportion.
> I don't think we should be quick to dismiss real cases just because
> they don't seem like the kind of thing _we_ would want to do. We
> should fix SRW's use of XML encoding to allow binary scan terms to get
_I_ don't want to do it either, it just happens that the Z server I'm
acting as a gateway to has them. But I can imagine other situations when
people would want to return arbitrary binary data.
The most SRW 1.1 friendly way that I can come up with to do this is that
the server could raise a new diagnostic saying 'unserializable terms, use
term encoding extension'
The client then redoes the scan with &x-info2-termEncoding, and the server
Then in 1.2 we drop the extension and make 'encoding' a real child of
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. University of Liverpool
I L L U M I N A T I L5R Shop: http://www.cardsnotwords.com/