OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [search-ws] [Issue] Search response can only return XML records


 
> What I am proposing is that the spec provide standard mechanisms for
> returning non-XML content and not leave it up to applications.

...

> How else would a client actually peel apart
> the non-XML content and do something useful with it unless it
> specifically knew what app specific wrapping was used?

a) a client can't actually do anything useful with binary information
unless it knows what format that binary information is (png, gif, bmp,
mov, jpg, mpg, wav, mp3, doc, xls, pdf, etc.) and also knows how to
handle that particular format.

b) as the XML record data can be any arbitrary XML structure, even for
non-binary data, the client still needs prior knowledge of the XML
format being returned.

What we engineered in SRU is that the protocol doesn't care what data is
being returned under recordData - the server has a means of telling a
client what structures are being returned, a client has a means of
requesting a particular record structure, and profiles are a means of
articulating what sort of structures a client or server should handle.

For interoperability between profiles we have mandated that all servers
and client should use a basic Dublin Core record structure.

Personally I think a better solution would be to have a normative XML
wrapper as described for passing binary content along the lines of:

<blob xmlmime:contentType="...">....</blob>

Which is one of the normative record structures that clients and servers
can use. In essence this is what you are proposing, but we make it a
record type rather than part of the protocol.

Matthew


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]