Why a SOAP interface? Suppose you have a site that is not
published on the internet. Or suppose you want to test your
feed before you deploy it. Of course, you can run it
locally, but even though we made it real easy, not everyone
wants to install and maintain another program. Wouldn't it be
nice if you could simply send your RSS feed off some
place and have the results sent back?
If I send something with multiple errors, should I be getting more than one error message back? I'm using a library I've never used before, so I'm not sure whether it's not giving them all to me, or you aren't.
If the errors are all of the same type, then it will only show you the first one. The support to show you all of them is already in the back-end of the code, all I need to do is make available a parameter to set this option.
If the errors are different, then it should be returning multiple entries.
And indeed it is returning multiple entries. It's just that when NuSoap sees the second message, it thinks you changed your mind and overwrites the values from the first message. Time for me to do some head scratching.
Yes, at the end of a very long story, but... they don't seem to have read your BDG to WSDL, so they insist that you pass precisely the parameters that they expect based on the WSDL, and if you don't get it right they absolutely refuse to send anything at all. Maybe they would correctly parse the response, but between the complete absence of even a hint of documentation and the incomprehensible fault messages, I'm reminded of those people who insist that you do exactly what they want you to do, without giving you even the slightest hint what that might be, and when you don't guess right just frown and shake their head at you. My policy for dealing with those people is to avoid them like the plague, so I think I'll try that with PEAR SOAP as well. If I can't debug NuSoap in another six or eight hours, I'll take ten minutes to write a single-purpose XML parser that'll just give me the messages I already know to expect, and if you break it by changing the response, I'll just fix it again. I'm willing to believe that SOAP and WSDL are quite nice with a decent library and someone who knows what they are doing, but at this point I've scratched several bloody spots on my head, and the fun is fading fast.
Oy. I'm learning more than I want to. All I wanted was a textarea where I could paste some RSS in, play around with it, and validate it, and now I've got one. I ended up just hacking NuSoap to tell it that if there's anything but a scalar in the root struct, then it's an array.
Am I right in thinking that what should happen is that when it parses the WSDL, it sees that a response consists of zero to unbounded messages, and so it treats response as an array?
That sandbox page is cool. I'm amazed that it gets the line numbers right as the server does not provide this correctly - at the moment I'm feeding the whole stream to the XML parser and relying on it to report back the line info. What I need to do is keep track of the first rss element and do a subtraction.
As to what should happen with that WSDL, let me answer on two levels. First, given the way PHP handles arrays, both a sequence of elements and an element with maxOccurs > 1 can both reasonably be mapped to an array. ASP.NET and Axis both map the latter case to arrays.
At another level, it is worth pointing out that RSS 2.0 specifies that a category contains an unbounded sequence of items, without ever specifying what this may map to, if anything, in whatever programming language you choose to use. The same is true here.
Posted by Sam Ruby at
You must have gotten lucky with the errors you tried, since I'm just using what the server gives me: mess with the RSS version attribute and you're told that the error is at the end element's position. Once Mozilla gets the ability to set the selection in a textarea I might try parsing the RSS myself so I know where start elements are and can translate from the end element error positions.
Spotted another one, the message element and its children are all qualified by the http://feeds.archive.org/validator/ namespace, but there's no elementFormDefault attribute set on the schema, and this defaults to unqualified, so the message element and its children should be unqualified [or the schmea should have elementFormDefault='qualified' added to it]
Dave Winer: Dave and I see some of the same data, but we interpret it differently. Here's my take. Where interfaces are of the simple client/server kind, and where all the state is on the server, the trend I see for the future is that new interfaces...
Trackback from Sam Ruby
Value of Uniform Interfaces
The first usage of RSS was to flow data from news producer to portals. Over time, this evolved into a flow from weblog servers to aggregators. One of the first truly novel uses of RSS is as a weblog archive format. In the case of Radio, this require...
Trackback from Sam Ruby
RSS validator SOAP interface
The RSS validator is sporting a spiffy new SOAP interface with a WSDL file to make your life easy...