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

Re: [soaplite] null namespace question

Expand Messages
  • Paul Kulchenko
    Hi, Douglas! Actually it shouldn t be a problem for you to access it. First, Never ever play with undocumented features unless it s documented ... (v0.50)
    Message 1 of 5 , Apr 27 9:17 AM
      Hi, Douglas!

      Actually it shouldn't be a problem for you to access it. First,
      "Never ever play with undocumented features unless it's documented"
      :)). Those funny prefixes (~C/~V) were dropeed in the last version
      (v0.50) and I hope they will never come back. All that you need to do
      to get an attributes, is to access element on server side with
      dataof() method instead of default valueof():

      -- server side --
      @ISA = 'SOAP::Server::Parameters'; # to get envelope

      sub mymethod {
      my $envelope = pop;
      print $envelope->dataof('//Name')->attr->{type};
      return;
      }

      will print 'Product' as expected. Next version will be much more
      namespace sensitive, but it won't affect this functionality. You
      should NOT rely on prefixes (if any), because next version will
      substitute namespaces in atributes (so, say 'a:something' will become
      'http://namespace/^something' with '^' as a separator).

      Basically dataof() returns SOAP::Data object for you where you have
      full access to all attributes and everything else. More information
      in docs. If you want to use attributes extensively, it might be
      better to specify deserializer and navigate with methods there. Take
      a look into examples/XML/customxml.pl. Hope it helps.

      Best wishes, Paul.

      --- Douglas Bonar <Doug.Bonar@...> wrote:
      >
      > A project I was working on mistakenly chose to use
      > the attribute 'type' for an internal meaning. In
      > our defense, we hadn't realized that its use was
      > specified in the SOAP standards doc, and the C++
      > and Java libraries that most of the tea are using
      > don't treat that attribute as special. When I tried
      > to construct messages through SOAP::Lite though,
      > the namespace of my 'type' attributes and of the
      > values got changed.
      >
      > Is there any way in SOAP-Lite to create the following
      > message:
      >
      > <?xml version="1.0" encoding="UTF-8"?>
      > <SOAP-ENV:Envelope
      > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
      > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
      > xmlns:xsd="http://www.w3.org/1999/XMLSchema"
      > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
      > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
      > >
      > <SOAP-ENV:Body
      > >
      > <GetValuesRequest
      > >
      > <Name type="Product"
      >
      >
      >csco.q</Name></GetValuesRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>
      >
      >
      > (without resorting to a freeform message, which I didn't try)?
      > The hard bit is getting the ' type="Product" ' attribute in the
      > 'Name' element.
      >
      > After some looking at the code, I realized that there are two
      > predefined 'generic namespaces', ~V and ~C. So one way I worked
      > around the problem was to build in a third, ~N. Like the first
      > two, you can use it in your attributes and values, and it will
      > be expanded to the correct string later. It "expands" to no
      > namespace though (including removing the ':' between it and the
      > actual string). That way I can use
      > ->attr({ '~N:type' => '~N:Product' })
      > on the Name object to give it a type attribute in the "null"
      > namespace. This was added by changing the three times where
      > the ~V and ~C namespaces are expanded (the three times the
      > string 'VC' occurs in Lite.pm I believe) with a slightly fancier
      > expansion.
      >
      > Of course, the standard does suggest that we shouldn't try
      > to use 'type' for our own purposes. So the project will change
      > and I won't have to use the above workaround. But I'm still
      > curious about if the namespaces on type can be avoided in
      > standard SOAP-Lite, and if anyone can think of any other use
      > for the above null namespace specifier.
      >
      >
      >
      > Doug
      >
      > To unsubscribe from this group, send an email to:
      > soaplite-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >


      __________________________________________________
      Do You Yahoo!?
      Yahoo! Auctions - buy the things you want at great prices
      http://auctions.yahoo.com/
    • Douglas Bonar
      ... That is (essentially) what I first got, but it has (to some parsers) two type attributes. Such parses are wrong, but given that the project thought of
      Message 2 of 5 , Apr 27 3:04 PM
        Duncan Cameron wrote:
        >
        > Doug
        >
        > Something like the following will produce what you're
        > looking for
        >
        > $r = $s->GetValuesRequest(
        > SOAP::Data->name('Name')->value('csco.q')->attr({type => 'Product'})
        > );
        >
        > The xml on the wire is
        >
        > <?xml version="1.0" encoding="UTF-8"?>
        > <SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
        > <SOAP-ENV:Body>
        > <namesp1:GetValuesRequest xmlns:namesp1="urn:Echo">
        > <Name xsi:type="xsd:string" type="Product">csco.q</Name>
        > </namesp1:GetValuesRequest>
        > </SOAP-ENV:Body></SOAP-ENV:Envelope>
        >
        > Regards,
        > Duncan Cameron
        >

        That is (essentially) what I first got, but it
        has (to some parsers) two type attributes. Such parses
        are wrong, but given that the project thought of using
        'type' as an attribute in the first place, would there
        be any way to work around them.

        Doug




        > On 2001-04-27 at 11:27:00, Douglas Bonar <Doug.Bonar@...> wrote concerning '[soaplite] null namespace question':
        > >A project I was working on mistakenly chose to use
        > >the attribute 'type' for an internal meaning. In
        > >our defense, we hadn't realized that its use was
        > >specified in the SOAP standards doc, and the C++
        > >and Java libraries that most of the tea are using
        > >don't treat that attribute as special. When I tried
        > >to construct messages through SOAP::Lite though,
        > >the namespace of my 'type' attributes and of the
        > >values got changed.
        > >
        > >Is there any way in SOAP-Lite to create the following
        > >message:
        > >
        > ><?xml version="1.0" encoding="UTF-8"?>
        > > <SOAP-ENV:Envelope
        > >xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
        > >xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
        > >xmlns:xsd="http://www.w3.org/1999/XMLSchema"
        > >SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
        > >xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
        > > >
        > > <SOAP-ENV:Body
        > > >
        > > <GetValuesRequest
        > > >
        > > <Name type="Product"
        > >
        > >>csco.q</Name></GetValuesRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>
        > >
        > >
        > >(without resorting to a freeform message, which I didn't try)?
        > >The hard bit is getting the ' type="Product" ' attribute in the
        > >'Name' element.
        > >
        > >After some looking at the code, I realized that there are two
        > >predefined 'generic namespaces', ~V and ~C. So one way I worked
        > >around the problem was to build in a third, ~N. Like the first
        > >two, you can use it in your attributes and values, and it will
        > >be expanded to the correct string later. It "expands" to no
        > >namespace though (including removing the ':' between it and the
        > >actual string). That way I can use
        > > ->attr({ '~N:type' => '~N:Product' })
        > >on the Name object to give it a type attribute in the "null"
        > >namespace. This was added by changing the three times where
        > >the ~V and ~C namespaces are expanded (the three times the
        > >string 'VC' occurs in Lite.pm I believe) with a slightly fancier
        > >expansion.
        > >
        > >Of course, the standard does suggest that we shouldn't try
        > >to use 'type' for our own purposes. So the project will change
        > >and I won't have to use the above workaround. But I'm still
        > >curious about if the namespaces on type can be avoided in
        > >standard SOAP-Lite, and if anyone can think of any other use
        > >for the above null namespace specifier.
        > >
        > >
        > >
        > >Doug
        >
        > To unsubscribe from this group, send an email to:
        > soaplite-unsubscribe@yahoogroups.com
        >
        >
      • Duncan Cameron
        Doug Something like the following will produce what you re looking for $r = $s- GetValuesRequest( SOAP::Data- name( Name )- value( csco.q )- attr({type =
        Message 3 of 5 , Apr 27 3:35 PM
          Doug

          Something like the following will produce what you're
          looking for

          $r = $s->GetValuesRequest(
          SOAP::Data->name('Name')->value('csco.q')->attr({type => 'Product'})
          );

          The xml on the wire is

          <?xml version="1.0" encoding="UTF-8"?>
          <SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
          <SOAP-ENV:Body>
          <namesp1:GetValuesRequest xmlns:namesp1="urn:Echo">
          <Name xsi:type="xsd:string" type="Product">csco.q</Name>
          </namesp1:GetValuesRequest>
          </SOAP-ENV:Body></SOAP-ENV:Envelope>

          Regards,
          Duncan Cameron


          On 2001-04-27 at 11:27:00, Douglas Bonar <Doug.Bonar@...> wrote concerning '[soaplite] null namespace question':
          >A project I was working on mistakenly chose to use
          >the attribute 'type' for an internal meaning. In
          >our defense, we hadn't realized that its use was
          >specified in the SOAP standards doc, and the C++
          >and Java libraries that most of the tea are using
          >don't treat that attribute as special. When I tried
          >to construct messages through SOAP::Lite though,
          >the namespace of my 'type' attributes and of the
          >values got changed.
          >
          >Is there any way in SOAP-Lite to create the following
          >message:
          >
          ><?xml version="1.0" encoding="UTF-8"?>
          > <SOAP-ENV:Envelope
          >xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
          >xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
          >xmlns:xsd="http://www.w3.org/1999/XMLSchema"
          >SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          >xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
          > >
          > <SOAP-ENV:Body
          > >
          > <GetValuesRequest
          > >
          > <Name type="Product"
          >
          >>csco.q</Name></GetValuesRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>
          >
          >
          >(without resorting to a freeform message, which I didn't try)?
          >The hard bit is getting the ' type="Product" ' attribute in the
          >'Name' element.
          >
          >After some looking at the code, I realized that there are two
          >predefined 'generic namespaces', ~V and ~C. So one way I worked
          >around the problem was to build in a third, ~N. Like the first
          >two, you can use it in your attributes and values, and it will
          >be expanded to the correct string later. It "expands" to no
          >namespace though (including removing the ':' between it and the
          >actual string). That way I can use
          > ->attr({ '~N:type' => '~N:Product' })
          >on the Name object to give it a type attribute in the "null"
          >namespace. This was added by changing the three times where
          >the ~V and ~C namespaces are expanded (the three times the
          >string 'VC' occurs in Lite.pm I believe) with a slightly fancier
          >expansion.
          >
          >Of course, the standard does suggest that we shouldn't try
          >to use 'type' for our own purposes. So the project will change
          >and I won't have to use the above workaround. But I'm still
          >curious about if the namespaces on type can be avoided in
          >standard SOAP-Lite, and if anyone can think of any other use
          >for the above null namespace specifier.
          >
          >
          >
          >Doug
        • Paul Kulchenko
          Hi, Doug! ... It depends WHAT is wrong. Attributes should be namespace qualified (except id and href attributes), so you can add namespace to your code: $r =
          Message 4 of 5 , Apr 28 8:12 AM
            Hi, Doug!

            > That is (essentially) what I first got, but it
            > has (to some parsers) two type attributes. Such parses
            > are wrong, but given that the project thought of using
            > 'type' as an attribute in the first place, would there
            > be any way to work around them.
            It depends WHAT is wrong. Attributes should be namespace qualified
            (except id and href attributes), so you can add namespace to your
            code:

            $r = $s->GetValuesRequest(
            SOAP::Data->name('Name')
            ->value('csco.q')
            ->attr({'a:type' =>'Product',
            'xmlns:a' => 'http://my.company/project'})
            );

            to make unique namespace. Alternatively, you may change attribute
            name. But in ideal world it shouldn't matter as soon as you have
            different namespace for your attribute.

            Best wishes, Paul.

            --- Douglas Bonar <Doug.Bonar@...> wrote:
            > Duncan Cameron wrote:
            > >
            > > Doug
            > >
            > > Something like the following will produce what you're
            > > looking for
            > >
            > > $r = $s->GetValuesRequest(
            > > SOAP::Data->name('Name')->value('csco.q')->attr({type =>
            > 'Product'})
            > > );
            > >
            > > The xml on the wire is
            > >
            > > <?xml version="1.0" encoding="UTF-8"?>
            > > <SOAP-ENV:Envelope
            > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
            > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
            > xmlns:xsd="http://www.w3.org/1999/XMLSchema"
            > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
            > > <SOAP-ENV:Body>
            > > <namesp1:GetValuesRequest xmlns:namesp1="urn:Echo">
            > > <Name xsi:type="xsd:string" type="Product">csco.q</Name>
            > > </namesp1:GetValuesRequest>
            > > </SOAP-ENV:Body></SOAP-ENV:Envelope>
            > >
            > > Regards,
            > > Duncan Cameron
            > >
            >
            > That is (essentially) what I first got, but it
            > has (to some parsers) two type attributes. Such parses
            > are wrong, but given that the project thought of using
            > 'type' as an attribute in the first place, would there
            > be any way to work around them.
            >
            > Doug
            >
            >
            >
            >
            > > On 2001-04-27 at 11:27:00, Douglas Bonar
            > <Doug.Bonar@...> wrote concerning '[soaplite] null
            > namespace question':
            > > >A project I was working on mistakenly chose to use
            > > >the attribute 'type' for an internal meaning. In
            > > >our defense, we hadn't realized that its use was
            > > >specified in the SOAP standards doc, and the C++
            > > >and Java libraries that most of the tea are using
            > > >don't treat that attribute as special. When I tried
            > > >to construct messages through SOAP::Lite though,
            > > >the namespace of my 'type' attributes and of the
            > > >values got changed.
            > > >
            > > >Is there any way in SOAP-Lite to create the following
            > > >message:
            > > >
            > > ><?xml version="1.0" encoding="UTF-8"?>
            > > > <SOAP-ENV:Envelope
            > > >xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
            > > >xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
            > > >xmlns:xsd="http://www.w3.org/1999/XMLSchema"
            > >
            > >SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
            > > >xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
            > > > >
            > > > <SOAP-ENV:Body
            > > > >
            > > > <GetValuesRequest
            > > > >
            > > > <Name type="Product"
            > > >
            > >
            >
            >>csco.q</Name></GetValuesRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>
            > > >
            > > >
            > > >(without resorting to a freeform message, which I didn't try)?
            > > >The hard bit is getting the ' type="Product" ' attribute in the
            > > >'Name' element.
            > > >
            > > >After some looking at the code, I realized that there are two
            > > >predefined 'generic namespaces', ~V and ~C. So one way I worked
            > > >around the problem was to build in a third, ~N. Like the first
            > > >two, you can use it in your attributes and values, and it will
            > > >be expanded to the correct string later. It "expands" to no
            > > >namespace though (including removing the ':' between it and the
            > > >actual string). That way I can use
            > > > ->attr({ '~N:type' => '~N:Product' })
            > > >on the Name object to give it a type attribute in the "null"
            > > >namespace. This was added by changing the three times where
            > > >the ~V and ~C namespaces are expanded (the three times the
            > > >string 'VC' occurs in Lite.pm I believe) with a slightly fancier
            > > >expansion.
            > > >
            > > >Of course, the standard does suggest that we shouldn't try
            > > >to use 'type' for our own purposes. So the project will change
            > > >and I won't have to use the above workaround. But I'm still
            > > >curious about if the namespaces on type can be avoided in
            > > >standard SOAP-Lite, and if anyone can think of any other use
            > > >for the above null namespace specifier.
            > > >
            > > >
            > > >
            > > >Doug
            > >
            > > To unsubscribe from this group, send an email to:
            > > soaplite-unsubscribe@yahoogroups.com
            > >
            > >
            >
            > To unsubscribe from this group, send an email to:
            > soaplite-unsubscribe@yahoogroups.com
            >
            >
            >
            > Your use of Yahoo! Groups is subject to
            > http://docs.yahoo.com/info/terms/
            >
            >


            __________________________________________________
            Do You Yahoo!?
            Yahoo! Auctions - buy the things you want at great prices
            http://auctions.yahoo.com/
          Your message has been successfully submitted and would be delivered to recipients shortly.