headers
Flubber Max | 8 Feb 2006 12:47
Picon
Picon
Favicon

XML-RPC Response and view it with a XSL

Hello.

I want view the XML response of XML-RPC directly in
the browser with a XSL but, i can't find good examples
to do it with structures iterance, arrays and data.

Someboy has a example or link with explaint to do it??

A lot of thanks.

I obtain XML-RPC responses like this:

<?xml version="1.0" encoding="iso-8859-1" ?>
<methodResponse>
   <params>
   <param>
<value>
  <array>
    <data>

<value>
  <struct>
    <member>
      <name>PAR_INI_CODIGO</name>
      <value><string>0838</string></value>
    </member>
    <member>
      <name>PAR_FIN_CODIGO</name>
      <value><string>1301</string></value>
    </member>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Ellzey | 8 Feb 2006 15:32
Picon

Larger than 32bit signed?

I have recently taken up a project which entails output of statistical
information. Many if not most of the other applications in the
enterprise use XML-RPC as a communications method and I wanted to do
the same for this one.

The problem that I run into is that the XML-RPC specification only
states an "i4" or 4 bytes signed for integers. I find it hard to
believe that no other developer has never wanted any number larger
than the ones provided.

Has there been any research done in the area of adding unsigned or 64
bit numbers to the specification? I understand I can just convert the
number to a string and have the application have the logic to convert
it, but that does not scale.

If this has been posted on the wrong mailing list I apologize ahead of time.

Thank you,
Mark

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> To unsubscribe from this group, send an email to:
    xml-rpc-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

Permalink | Reply | 22 comments |
headers
Gaetano Giunta | 8 Feb 2006 16:16
Picon

RE: Larger than 32bit signed?

A lot of other useful data types miss from the lib.
NULL for example would make it a breeze to move around stuff gotten out of databases.

But (imho), simplicity is one of the strengths of the spec, rather than a weakness: the core datatypes can be
defined/used in pretty much any language/platform under the sun, and libs are a breeze to implement.

Otoh if you take the basic data types used in SOAP, which tend to be derived from XSD, there are so many that
just deciding which one to pick for a particular variable can be a time-consuming and error-prone process
(19 simple types plus those derived). And I guess many toolkits out there only have very limited support
for many of those types.

If you use the same xmlrpc toolkit on both ends of the communication, you migth be lucky: the toolkit in
question could possibly make use of the maximum native integer type available on the platform, and have no
problem in receiving or sending 8-byte integers.
If the toolkit in question did not support 8-byte integers, yould could of course hack it into the toolkit.
Or just use a string value for that particular bigint data field.

If you are looking forward to real interop, then you are out of luck: the spec has been frozen since about 1999
and there are very little chances that a spec extension, whoever proposed it, would be implemented by a
large part of the existing toolkits (I can count more than a dozen tolkits for php alone...).

Just my 2C
Gaetano Giunta

> -----Original Message-----
> From: xml-rpc <at> yahoogroups.com 
> [mailto:xml-rpc <at> yahoogroups.com]On Behalf
> Of Mark Ellzey
> Sent: Wednesday, February 08, 2006 3:32 PM
> To: xml-rpc <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Wilson | 8 Feb 2006 16:29
Picon

Re: Larger than 32bit signed?


On 8 Feb 2006, at 14:32, Mark Ellzey wrote:

> I have recently taken up a project which entails output of statistical
> information. Many if not most of the other applications in the
> enterprise use XML-RPC as a communications method and I wanted to do
> the same for this one.
>
> The problem that I run into is that the XML-RPC specification only
> states an "i4" or 4 bytes signed for integers. I find it hard to
> believe that no other developer has never wanted any number larger
> than the ones provided.
>
> Has there been any research done in the area of adding unsigned or 64
> bit numbers to the specification? I understand I can just convert the
> number to a string and have the application have the logic to convert
> it, but that does not scale.

The strength of XML-RPC is the interoperability. The spec has been  
stable for years now and I see no real chance that it will get  
changed now.

Why doesn't using strings "scale"?

You can use double, of course, which gives you a continuous Integer  
range of +- 2**52.

Just how big are the numbers you want to send?

John Wilson
(Continue reading)

Permalink | Reply | 15 comments |
headers
Mark Ellzey | 8 Feb 2006 17:10
Picon

Re: Larger than 32bit signed?

>
>
> The strength of XML-RPC is the interoperability. The spec has been
> stable for years now and I see no real chance that it will get
> changed now.
>

This is an unfortunate way to see this technology.

> Why doesn't using strings "scale"?

Because the app or user must have previous knowledge of this string or
datatype to be converted. This seems like one of the issues that
xml-rpc was trying to fix, I may be wrong in that notion.

>
> You can use double, of course, which gives you a continuous Integer
> range of +- 2**52.
>
>
> Just how big are the numbers you want to send?

greater than or equal to 4,294,967,295. I would love to be able to use
64 bit numbers.

It sounds like the best bet here is to use a structure defining what
the data-type actually is but use strings. Thanks for the reply.

 
Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 14 comments |
headers
Nathan Young | 8 Feb 2006 18:44

Re: Larger than 32bit signed?

Hi.

The issue "XML-RPC doesn't do what I need, can we add x to it?" has come  
up so many times.  Really, search the archives and you will find literally  
hundreds of lively well thought out discussions about just this.

The owner of the spec (Dave Winer) is loath to change it, because of all  
the interoperating implementations and I think at this point just about  
every library owner shares that view, irrespective of how good they think  
any particular change would be.  This applies not just to the official  
spec itself, but to any spec purporting to apply to "XML-RPC".

I remember one solution that seemed to make sense, and I'm fairly certain  
Dave approved of the approach as well, if he's still lurking on this list  
he could confirm.

The solution was to create a spec for a language and call it "most  
definitely not XML-RPC, call it anything else you want".  In the spec, say  
"this is XML-RPC plus (or minus) feature X".  Make sure the  
implementations you use on both ends support the new protocol and you are  
off and running.  The assertion was that the more widely needed the new  
feature was, the more widely implemented it would be by the owners of the  
various XML-RPC libraries.

I'm fairly certain this has been followed a number of times but I know of  
no case where any new features have been implemented beyond what the  
original requestor needed to have to get his job done.  99% of people  
everywhere are using plain vanilla XML-RPC and loving it.  (as long as  
they don't care about dates, locales, error codes or database  
interoperability :)
(Continue reading)

Permalink | Reply | 13 comments |
headers
bryanh | 8 Feb 2006 18:51

Re: Larger than 32bit signed?

>The owner of the spec (Dave Winer) is loath to change it,

Dave isn't the owner of anything significant.  He controls one file on
the Internet and possibly the name XML-RPC, but those aren't
significant.

People with these proposals to extend XML-RPC speak as if their
problems would be solved if Dave Winer would endorse the extension and
change his file.  That would barely begin to solve any problem,
because what needs to change is substantially all of the XML-RPC
clients and servers in the world.  If you want interoperability, it
doesn't matter that some document or person says a server _should_
know what <i8> means.  What matters is if a client developer can
expect it actually to do so.

"Changing" a spec means issuing a new spec.  The old one is still
there and can still be referred to.  A code library that implements
the original spec still implements it -- correctly.  Furthermore,
issuing a new spec is nothing more than _proposing_ different
implementations.

Anyone can publish a new XML-RPC spec (probably using a different name
for it) that has <i8>.  Dave Winer and xmlrpc.com notwithstanding.
I know of several extensions to XML-RPC that have been published as
standards, and several more that are invented by the various XML-RPC
libraries.

Some specs occupy a world that is so dynamic that proposing more
powerful implementations results in those implementations happening,
and before long one can safely assume that one's communication
(Continue reading)

Permalink | Reply | 12 comments |
headers
Aleksandar Janicijevic | 9 Feb 2006 20:22
Picon
Favicon

Re: Larger than 32bit signed?

Hi All,

Just to add my humble view on this matter, I am both
against any change in the XML-RPC and against making a
new extended standard that would replace it. Here are
my reasons: 1 - that would defeat the purpose of
XML-RPC, and 2 - the present standard is sufficient.

1 - Once we start messing with the standard and
extending it, we will no longer have a simple, stable
standard for which it is easy to write compliant
client and servers. There will be no consensus what
extensions should be adopted and the standard will
fork to several standards. We would lose universal
interoperability. That would be hell. Besides, what if
I have a 32-bit machine that doesn't support 64-bit
numbers natively? Then I cannot have XML-RPC clients
or servers?

2 - You can implement long integers in the present
standard if you wish. Just don't encode them as i4,
but as base64. This slows things down because now a
conversion is required on both sides, but makes it
much more flexible. For example, sometimes you might
need numbers that are much larger that 64-bit -
applications in cryptography comes to mind.

Does this make sense?

Regards,
(Continue reading)

Permalink | Reply | 11 comments |
headers
Marc Conrad | 9 Feb 2006 21:39
Picon

Re: Larger than 32bit signed?

Hi, 

I fully agree with keeping the standard as is, for 
the reasons iterated in a number of other 
messages. Even more, such an extended standard 
is alive and exists if we choose to believe Wikipedia: 

"[XML-RPC] was first created by Dave Winer of UserLand 
Software in 1995 with Microsoft. However, Microsoft considered it 
too simple and started adding functionality. After several rounds of
this, 
the standard was no longer so simple and became what is now SOAP."

http://en.wikipedia.org/wiki/XML-RPC (as of 09 February 2006)

I use XML-RPC for my teaching in Distributed Computing because it has 
all the essentials necessary for a Distributed Application and not much
else
that distracts from the real issue, or to say the same differently: 

If I teach CORBA, my students  learn CORBA
If I teach RMI, my students learn RMI
If I teach SOAP, my students learn SOAP
If I teach XML-RPC, my students learn Distributed Computing. 

Cheers, Marc

--
Marc Conrad - Luton, Southampton, Merzig, Podstrana
http://perisic.com/marc
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Ellzey | 9 Feb 2006 22:01
Picon

Re: Larger than 32bit signed?

So the short answer to all of this is: "no there is never going to be
a change in the spec". I thought that native support of common
integral data types were something the general community could use,
but I was mistaken. The fact that xml-rpc does not have a version
specification makes any additions impossible.

I apologize to those who have answered this question before. Yes I did
do a search - but my search was specific to signed/unsigned integers.

Thank you all for your opinions and answers.

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xml-rpc/

<*> To unsubscribe from this group, send an email to:
    xml-rpc-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 8 comments |

Gmane