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
> there.
>> 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

Yep.


> 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.

Yep.

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
set already.
I think that cql.base64 is required outside of any binary scan term
discussion.


>> 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
returns:

<term>
   <value>...</value>
   <extraTermData>
     <foo:encoding>base64<foo:encoding>
   </extraTermData>
</term>

Then in 1.2 we drop the extension and make 'encoding' a real child of
'term'.

Rob

       ,'/:.          Dr Robert Sanderson ([log in to unmask])
     ,'-/::::.        http://www.o-r-g.org/~azaroth/
   ,'--/::(@)::.      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/