> -----Original Message----- > From: Kurt Ward [mailto:[EMAIL PROTECTED] > Sent: 19 February 2002 00:08 > To: [EMAIL PROTECTED] > Subject: Re: Switch to XML-RPC / SOAP > > > > > Unless I'm overlooking something, I think SOAP is a > little overkill for > > > Xindice > > > since the data returned will most likely always be XML and not a > datatyped > > > response. > > > What do you guys think? > > > > The one thing that is appealing about SOAP is that it > supports multiple > > encodings so it would enable something like our XML:DB API impl to > > negotiate with the server to use a binary encoding while > less intelligent > > clients use regular encodings. Right now one of the > benefits of the CORBA > > API is that it doesn't parse the document if it doesn't > have too, with > > SOAP you could achieve the same thing. We could actually > achieve the same > > effect with XML-RPC through a method on a parameter, but > that alters the > > interface. > > Good point. >
As you guys probably know, I'm really trying to get full Unicode support for documents in Xindice, and one of the reasons for switching to XML-RPC or SOAP or whatever is to get around some issues with CORBA on this front. Now reading the XML-RPC book from O'Reilly, I discovered that String types in XML-RPC can be only ASCII! No other charcaters than those first 127 are garanteed by the specification to be supported by XML-RPC software. As O'Reilly point out, this doesn't rule out one or the other implementation actually supporting other characters to a varying degree; it just isn't garanteed. Now even if Apache XML-RPC does support the whole thing fully, this kind of thing gives me the willies, and I'd really prefer our interface being defined in some langauge that GARANTEED that all our data needs will be addressed... I haven't read the SOAP book in detail yet, but as IO understand it, SOAP types are based on XML Schema types, and xsd:string supports any string of unicode characters, thus hopefully showing SOAP does address the issue correctly. > > That being said, I really prefer to take as simple of an approach as > > possible to start with and that is really XML-RPC. So I'm > +1 for XML-RPC. This is true: SOAP seems more complicated to get going. But to garantee full support for strings in XML-RPC, we might need to do a fair bit of work on top to encode/decode the strings, negociate encodings etc... In addition, as far as I can make out, XML-RPC doesn't even support XML fragments as a datatype? How then would we pass search results, or documents accross the API? As base64 encoded byte arrays of utf-8 encoded XML? or as XML-RPC strings with the necessary escapes of all non-ASCII characters?
