I do not have a strong opnion on this, but a distinction between recordData and recordXML could be usefull for gateway-like applications. Records are better "selfdescribing" when you can count on the fact that one is XML and the other is string. 

Theo
PS Using http://krait.kb.nl/coop/tel/portal/srudbs.xml for searching in your database, I do not really get Dublin Core but only nested numbered tags (use diagnostic layout in the search page to view the results).


>>> [log in to unmask] 13-04-03 22:02 >>>
Ray asked me to resend this with a different Subject:

Okay, I've decided to give up on this.  I have a counterproposal instead.

I've sent notes off to the Apache Axis folks describing our problem.  The
notes were ignored.  I take this to mean that it isn't possible.

I've sent notes off to the XSL list, hoping that we could maybe get our
stylesheets to cope with the encoded records.  One guys responds that it
can't be done, another says that it is built into the Saxon processor.
Neither solution helps.

So I've decided to declare this to be a non-problem.

My SRU server just takes the request and reformats it as a SOAP request,
sends it to the SOAP server, gets the SOAP response, cleans that up and
returns it.  It's the "cleans that up" part that is our opportunity.

Right now, my SRU server strips off the SOAP wrapper from the
searchRetrieveResponse and removes any xsi:type="whatever" strings.  I have
added logic to also replace any <, > and " strings with the
appropriate value.  Suddenly, SRU is returning the records as subfields of
the recordData field.

I think that is our solution.  Forget about the recordPacking and recordXML
fields.  Return string-encoded records in SRW and non-string-encoded records
in SRU.

This code is now in place in my server on Alcme.oclc.org.  (The same one
you've been pointing at.)

Ralph