We use doc/literal style (to be WS-I 1.1 compliant) so xsi:type shouldn't really be being generated in either SRW or SRU. However, their presence doesn't do any harm.
No SRU or SRW client or server should be expecting or relying on their presence or absence.
My recommendation would be to tweak the apache engine (I suspect it may be configured to do encoded rather than literal somewhere - I've not touched Apache SOAP for a little while but my recollection is that it doesn't generate xsi:types in literal mode) so that it doesn't generate the xsi:type in the first place.
Matthew
> -----Original Message-----
> From: SRU (Search and Retrieve Via URL) Implementors
> [mailto:[log in to unmask]] On Behalf Of LeVan,Ralph
> Sent: 11 March 2008 18:38
> To: [log in to unmask]
> Subject: To Strip xsi:type or Not To Strip?
>
> I use the Apache SOAP engine for both my SRW and SRU services. I run
> everything internally as SRW and strip off the SOAP bits if I'm
> delivering SRU.
>
>
>
> But, when I strip off the SOAP header, I was also stripping of the xsi
> namespace declaration, which made the xsi:type attributes in the SRU
> response invalid. So, I stripped the xsi:type attributes out too.
>
>
>
> But, I've got a user that wants to deliver up records in an SRU
> response that contain xsi:type. The easiest fix is to put the xsi
> namespace declaration into the searchRetrieveResponse element and leave
> all the xsi:type attributes in the response. The harder fix is to
> suppress the fiddling inside the user content.
>
>
>
> How evil will I look if my SRU responses start including xsi:type
> attributes in all the elements?
>
>
>
> Thanks!
>
>
>
> Ralph
|