Welcome to the "trac"-ing site of soap4r!
[soap4r] [httpclient] [openpgp4u] [pkcs1] [logger] [csv] [vtr]

Ticket #179 (closed defect: invalid)

Opened 4 years ago

Last modified 4 years ago

Prefixes in xsi:type="..." other than xsd: don't work

Reported by: anonymous Assigned to: nahi
Priority: high Milestone: 1.5.6
Component: soap4r Version: 1.5
Keywords: Cc:

Description

It doesn't matter what prefix you're using for for xsi:type. Eg. "bla:int" is right, too, if the right namespace is declared in the root-element. A very good example is http://developer.mozilla.org/en/docs/SOAP_in_Gecko-based_Browsers, that shows, that the response doesn't have to follow the request's prefix. The calc-sample of soap4r doesn't work with Mozilla's SOAP-Implementation, because they use xs: as the prefix for the shema namespace, eg. xsi:type="xs:int". soap4r can't handle this right and takes the default, a string! Even in the SOAP specifications it's defined, that the prefix doesn't matter.

Change History

11/08/05 12:07:01 changed by nahi

  • milestone changed from undefined to 1.5.6.

Thank you for filing it.

Yes, it must be supported by soap4r. I added the following to client.rb in sample/soap/calc but it seems to work without any problem. Client sends with 'xs:int' and Server returns with 'xsd:int'. Client detects it as Fixnum in Ruby.

module SOAP

XSDNamespaceTag = 'xs' # or 'helloworld' etc.

end

There should be some interoperability problem between Mozilla's SOAP-Implementation and soap4r. Would you please tell me how I can reproduce the error?

11/11/05 03:13:35 changed by turbo24prg@web.de

The following shows, that the server returns "12" and not the expected 3. 

<html>
  <head>
    <title>Calc</title>
    <script>
      function calc() {
        netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");

        var CalcCall = new SOAPCall();
        CalcCall.transportURI = "http:///";

        var param1 = new SOAPParameter();
        param1.value = 1;
        param1.name = "lhs";
            
        var param2 = new SOAPParameter();
        param2.value = 2;
        param2.name = "rhs";

        var myParamArray = [param1,param2];
           
        CalcCall.encode(0, "add", "http://tempuri.org/calcService", 0, null, myParamArray.length, myParamArray);

        var result = CalcCall.invoke();

        if(result.fault){
           alert(result.fault.faultString);
        } else {
          var response = new Array();
          response = result.getParameters(false, {});
          alert("Result: " + response[0].value);  
        }
      } 
    </script>
  </head>
  <body>
    <a href="javascript:calc();">Run Example</a>
  </body>
</html>

Just declaring another XSDNamespaceTag manually isn't a good idea. The prefix used by the client should be parsed from the root element: 

  <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
              xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
              env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
              xmlns:xs="http://www.w3.org/1999/XMLSchema"
              xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">

So, probably the best solution is to do an XPath-Query on the root elment, looking for the namespace "http://www.w3.org/1999/XMLSchema".

Thanks.

11/11/05 06:47:56 changed by nahi

Thanks. Hmm. Old XMLSchema definition. Would you please add 

require 'xsd/datatypes1999'

to your client? It's for XMLSchema 1999.

11/11/05 23:22:22 changed by turbo24prg@web.de

I noticed, that you aare speaking from a client. I use soap4r as the server. The client is in JavaScript?!

* Adding require 'xsd/datatypes1999' to the server works, but is useless because Mozilla's API works just fine even without it.

* XSDNamespaceTag = 'xs' is ruby and not JavaScript?. Even if it would be possible to tell the client that he must use a pre-defined prefix is bad - if I would set it to "foobar" it should work fine, too.

Just defining globally that the prefix is everytime "xs", or "xsd" is a dirty hack. Making the server available for all SOAP-Implementations would be very fine - the client-coders shouldn't care what prefixes they should use for my server.

I'll have a look at the sources this evening, trying to understand what should be done in soap4r.

Thanks.

11/12/05 16:15:46 changed by nahi

Sorry for client/server confusion.

I'm afraid that I don't understand your point. SOAP4R handles XMLSchema 2001 version (W3C Recommended). You need to require 'xsd/datatypes1999' to use XMLSchema 1999 version (old, not recommended). Both client and server. Soap4r uses XML Namespace compliant implementation so any tag assignment is allowed.

I'm looking for your comment about what is the problem of soap4r after your inspection. Thanks in advance.

11/12/05 22:48:18 changed by turbo24prg@web.de

I had the same opinion like you, but after chatting with some mozilla developers in their IRC-Channel I understood, that I was wrong thinking they did a mistake with xsi:type="xs:int".

The namespace is an URI like "http://www.w3.org/1999/XMLSchema". Mozilla's implementation and soap4r understand both XMLSchema 1999 and 2001, so it really doesn't matter wich of this two namespaces you would use.

The prefix is just the (nick)name of the namespace. It's defined in the root element with xmlns:foobar="URI". Every prefix is valid for an namespace. There aren't any pre-defined prefixes for a namespace.

In soap.rb you're defining XSDNamespaceTag, but this is completly wrong. The namespace is defined in the XMLs root-element straight because it should be used to determine what prefix is used for the XML Shema Namespace in this XML document. Just defining it globally as a constant is wrong.

The prefix' name is defined in each XML-request's root-element and should not be declared globally in soap.rb Got it?

Thanks for your interest.

11/12/05 22:56:26 changed by nahi

  • status changed from new to closed.
  • resolution set to invalid.

Please see where XSDNamespaceTag is *used*.

FYI: XML Namespace definition is allowed in any element.