Loading ...
Sorry, an error occurred while loading the content.

Removal Of Namespace Prefix From Element

Expand Messages
  • jameshargreavesgmail
    Hi I m still having trouble with NuSOAP in case anyone has a solution to my previous posting? On another issue I am trying to create a client for the same
    Message 1 of 5 , Apr 1 6:05 AM
    • 0 Attachment
      Hi

      I'm still having trouble with NuSOAP in case anyone has a solution to
      my previous posting?

      On another issue I am trying to create a client for the same service
      using gSOAP. I am currently receiving the following error:

      "Tag mismatch: element 'namesp1:loginResponse' does not correspond to
      expected element"

      which I believe is because it does not understand the namesp1 prefix
      on the loginResponse element:

      <namesp1:loginResponse xmlns:namesp1="urn:SOAPAtlas">

      Is there some way I can force my output to be as follows:

      <loginResponse xmlns="urn:SOAPAtlas">

      Thanks
      Jay
    • Byrne Reese
      In 0.60 and 0.65_3 there is a subroutine called use_prefix(true|false) which turns on|off default namespacing. In the full release of 0.65 I will probably
      Message 2 of 5 , Apr 1 6:37 AM
      • 0 Attachment
        In 0.60 and 0.65_3 there is a subroutine called use_prefix(true|false)
        which turns on|off default namespacing.

        In the full release of 0.65 I will probably deprecate this function and
        rename it to "use_default_ns(true|false)."

        I am also considering using default namespaces by default. Anyone have
        any thoughts on this proposal?

        jameshargreavesgmail wrote:

        >
        > Hi
        >
        > I'm still having trouble with NuSOAP in case anyone has a solution to
        > my previous posting?
        >
        > On another issue I am trying to create a client for the same service
        > using gSOAP. I am currently receiving the following error:
        >
        > "Tag mismatch: element 'namesp1:loginResponse' does not correspond to
        > expected element"
        >
        > which I believe is because it does not understand the namesp1 prefix
        > on the loginResponse element:
        >
        > <namesp1:loginResponse xmlns:namesp1="urn:SOAPAtlas">
        >
        > Is there some way I can force my output to be as follows:
        >
        > <loginResponse xmlns="urn:SOAPAtlas">
        >
        > Thanks
        > Jay
        >
        >
        >
        >
        > ------------------------------------------------------------------------
        > *Yahoo! Groups Links*
        >
        > * To visit your group on the web, go to:
        > http://groups.yahoo.com/group/soaplite/
        >
        > * To unsubscribe from this group, send an email to:
        > soaplite-unsubscribe@yahoogroups.com
        > <mailto:soaplite-unsubscribe@yahoogroups.com?subject=Unsubscribe>
        >
        > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        > Service <http://docs.yahoo.com/info/terms/>.
        >
        >
      • Joe Hourcle
        ... I d probably prefer: use_default_ns( true | false | string ) Where if you could then feed in a string to be used rather than the automatic numbering of
        Message 3 of 5 , Apr 1 7:13 AM
        • 0 Attachment
          On Fri, 1 Apr 2005, Byrne Reese wrote:

          >
          > In 0.60 and 0.65_3 there is a subroutine called use_prefix(true|false)
          > which turns on|off default namespacing.
          >
          > In the full release of 0.65 I will probably deprecate this function and
          > rename it to "use_default_ns(true|false)."
          >
          > I am also considering using default namespaces by default. Anyone have
          > any thoughts on this proposal?

          I'd probably prefer:

          use_default_ns( true | false | string )

          Where if you could then feed in a string to be used rather than the
          automatic numbering of namespaces. (so I can be lazy, and not have to
          specify all of my items in the serializer's type mapping, or write my own
          serializer, just so I can override maptypetouri().)


          Of course, I haven't actually looked at the current beta, so I don't know
          what's changed from the version that I've been hacking at (0.60a), so what
          sort of other implications this might have, or if this has been resolved
          through other means.

          -----
          Joe Hourcle
        • Juan Fco Rodriguez
          ... Hello, I m newbie to all this stuff, but I was having problems trying to always get the same autogenerated namespace on the element, so I
          Message 4 of 5 , Apr 4 9:16 AM
          • 0 Attachment
            On Fri, 1 Apr 2005, Joe Hourcle wrote:

            >
            >
            >
            >
            > On Fri, 1 Apr 2005, Byrne Reese wrote:
            >
            >>
            >> In 0.60 and 0.65_3 there is a subroutine called use_prefix(true|false)
            >> which turns on|off default namespacing.
            >>
            >> In the full release of 0.65 I will probably deprecate this function and
            >> rename it to "use_default_ns(true|false)."
            >>
            >> I am also considering using default namespaces by default. Anyone have
            >> any thoughts on this proposal?
            >
            > I'd probably prefer:
            >
            > use_default_ns( true | false | string )

            Hello,

            I'm newbie to all this stuff, but I was having problems trying
            to always get the same autogenerated namespace on the <...Response>
            element, so I would greatly appreciate to be able to specify the
            namespace as a string, as Joe suggests in his mail. I needed to
            refer to the autogenerated namespace in nested elements...then
            I realized that I could do it in other way so I dont have this
            problem any more, but it might be interesting to let users select
            the default namespace beside turn it on or off. I'm full of doubts,
            but hope this helps :P



            >
            > Where if you could then feed in a string to be used rather than the
            > automatic numbering of namespaces. (so I can be lazy, and not have to
            > specify all of my items in the serializer's type mapping, or write my own
            > serializer, just so I can override maptypetouri().)
            >
            >
            > Of course, I haven't actually looked at the current beta, so I don't know
            > what's changed from the version that I've been hacking at (0.60a), so what
            > sort of other implications this might have, or if this has been resolved
            > through other means.
            >
            > -----
            > Joe Hourcle
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >
            >
            > _____________________________________________________________________
            > Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es
            >

            _____________________________________________________________________
            Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es
          • Byrne Reese
            Your wish is my command.... =-D In 0.65_5, the following two subroutines will be introduced that I intend to replace uri() and use_prefix() with...
            Message 5 of 5 , Apr 4 9:39 AM
            • 0 Attachment
              Your wish is my command.... =-D

              In 0.65_5, the following two subroutines will be introduced that I
              intend to replace uri() and use_prefix() with...

              *default_ns($uri)* - Sets the default namespace for the request to the
              specified uri. This overrides any previous namespace declaration that
              may have been set using a previous call to |ns()| or |default_ns()|.
              Setting the default namespace causes elements to be serialized without a
              namespace prefix, like so:

              <soap:Envelope>
              <soap:Body>
              <myMethod xmlns="http://www.someuri.com">
              <foo />
              </myMethod>
              </soap:Body>
              </soap:Envelope>

              *ns($uri,$prefix=undef) *- Sets the namespace uri and optionally the
              namespace prefix for the request to the specified values. This overrides
              any previous namespace declaration that may have been set using a
              previous call to |ns()| or |default_ns()|. If a prefix is not specified,
              one will be generated for you automatically. Setting the namespace
              causes elements to be serialized with a namespace prefix, like so:

              <soap:Envelope>
              <soap:Body>
              <my:myMethod xmlns:my="http://www.someuri.com">
              <my:foo />
              </my:myMethod>
              </soap:Body>
              </soap:Envelope>

              This documentation is available at:
              http://www.majordojo.com/soaplite/docs/

              Juan Fco Rodriguez wrote:

              > On Fri, 1 Apr 2005, Joe Hourcle wrote:
              >
              >> On Fri, 1 Apr 2005, Byrne Reese wrote:
              >>
              >>>
              >>> In 0.60 and 0.65_3 there is a subroutine called use_prefix(true|false)
              >>> which turns on|off default namespacing.
              >>>
              >>> In the full release of 0.65 I will probably deprecate this function and
              >>> rename it to "use_default_ns(true|false)."
              >>>
              >>> I am also considering using default namespaces by default. Anyone have
              >>> any thoughts on this proposal?
              >>
              >>
              >> I'd probably prefer:
              >>
              >> use_default_ns( true | false | string )
              >
              >
              > Hello,
              >
              > I'm newbie to all this stuff, but I was having problems trying
              > to always get the same autogenerated namespace on the <...Response>
              > element, so I would greatly appreciate to be able to specify the
              > namespace as a string, as Joe suggests in his mail. I needed to
              > refer to the autogenerated namespace in nested elements...then
              > I realized that I could do it in other way so I dont have this
              > problem any more, but it might be interesting to let users select
              > the default namespace beside turn it on or off. I'm full of doubts,
              > but hope this helps :P
              >
              >
              >
              >>
              >> Where if you could then feed in a string to be used rather than the
              >> automatic numbering of namespaces. (so I can be lazy, and not have to
              >> specify all of my items in the serializer's type mapping, or write my
              >> own
              >> serializer, just so I can override maptypetouri().)
              >>
              >>
              >> Of course, I haven't actually looked at the current beta, so I don't
              >> know
              >> what's changed from the version that I've been hacking at (0.60a), so
              >> what
              >> sort of other implications this might have, or if this has been resolved
              >> through other means.
              >>
              >> -----
              >> Joe Hourcle
              >>
              >>
              >>
              >> Yahoo! Groups Links
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >> _____________________________________________________________________
              >> Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es
              >>
              >
              > _____________________________________________________________________
              > Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es
            Your message has been successfully submitted and would be delivered to recipients shortly.