Provided by: libnet-xmpp-perl_1.05-1_all bug


       Net::XMPP::Namespaces - In depth discussion on how namespaces are handled


       Net::XMPP::Namespaces provides an depth look at how Net::XMPP handles namespacs, and how
       to add your own custom ones.  It also serves as the storage bin for all of the Namespace
       information Net::XMPP requires.


       XMPP as a protocol is very well defined.  There are three main top level packets (message,
       iq, and presence).  There is also a way to extend the protocol in a very clear and
       strucutred way, via namespaces.

       Two major ways that namespaces are used in Jabber is for making the <iq/> a generic
       wrapper, and as a way for adding data to any packet via a child tag <x/>.  We will use
       <x/> to represent the packet, but in reality it could be any child tag: <foo/>, <data/>,
       <error/>, etc.

       The Info/Query <iq/> packet uses namespaces to determine the type of information to
       access.  Usually there is a <query/> tag in the <iq/> that represents the namespace, but
       in fact it can be any tag.  The definition of the Query portion, is the first tag that has
       a namespace.

           <iq type="get"><query xmlns="..."/></iq>


           <iq type="get"><foo xmlns="..."/></iq>

       After that Query stanza can be any number of other stanzas (<x/> tags) you want to
       include.  The Query packet is represented and available by calling GetQuery() or
       GetChild(), and the other namespaces are available by calling GetChild().

       The X tag is just a way to piggy back data on other packets.  Like embedding the timestamp
       for a message using jabber:x:delay, or signing you presence for encryption using

       To this end, Net::XMPP has sought to find a way to easily, and clearly define the
       functions needed to access the XML for a namespace.  We will go over the full docs, and
       then show two examples of real namespaces so that you can see what we are talking about.

       To avoid a lot of nasty modules populating memory that are not used, and to avoid having
       to change 15 modules when a minor change is introduced, the Net::XMPP modules have taken
       AUTOLOADing to the extreme. is nothing but a set of function calls that
       generates a big hash of hashes.  The hash is accessed by the AUTOLOAD function
       to do something.  (This will make sense, I promise.)

       Before going on, I highly suggest you read a Perl book on AUTOLOAD and how it works.  From
       this point on I will assume that you understand it.

       When you create a Net::XMPP::IQ object and add a Query to it (NewChild) several things are
       happening in the background.  The argument to NewChild is the namespace you want to add.

       Now that you have a Query object to work with you will call the GetXXX functions, and
       SetXXX functions to set the data.  There are no defined GetXXX and SetXXXX functions.  You
       cannot look in the file and find them.  Instead you will find something like

         &add_ns(ns    => "mynamespace",
                 tag   => "mytag",
                 xpath => {
                           JID       => { type=>'jid', path => '@jid' },
                           Username  => { path => 'username/text()' },
                           Test      => { type => 'master' }

       When the GetUsername() function is called, the AUTOLOAD function looks in the hash for a "Username" key.  Based on the "type" of the field (scalar being
       the default) it will use the "path" as an XPath to retrieve the data and call the
       XPathGet() method in

       Confused yet?

   Net::XMPP private namespaces
       Now this is where this starts to get a little sticky.  When you see a namespace with
       __netxmpp__, or __netjabber__ from Net::Jabber, at the beginning it is usually something
       custom to Net::XMPP and NOT part of the actual XMPP protocol.

       There are some places where the structure of the XML allows for multiple children with the
       same name.  The main places you will see this behavior is where you have multiple tags
       with the same name and those have children under them (jabber:iq:roster).

       In jabber:iq:roster, the <item/> tag can be repeated multiple times, and is sort of like a
       mini-namespace in itself.  To that end, we treat it like a separate namespace and defined
       a __netxmpp__:iq:roster:item namespace to hold it.  What happens is this, in my code I
       define that the <item/>s tag is "item" and anything with that tag name is to create a new
       Net::XMPP::Stanza object with the namespace __netxmpp__:iq:roster:item which then becomes
       a child of the jabber:iq:roster Stanza object.  Also, when you want to add a new item to a
       jabber:iq:roster project you call NewQuery with the private namespace.

       I know this sounds complicated.  And if after reading this entire document it is still
       complicated, email me, ask questions, and I will monitor it and adjust these docs to
       answer the questions that people ask.

       To repeat, here is an example call to add_ns():

           add_ns(ns    => "mynamespace",
                   tag   => "mytag",
                   xpath => {
                             JID       => { type=>'jid', path => '@jid' },
                             Username  => { path => 'username/text()' },
                             Test      => { type => 'master' }

       ns - This is the new namespace that you are trying to add.

       tag - This is the root tag to use for objects based on this namespace.

       xpath - The hash reference passed in the add_ns call to each name of entry tells Net::XMPP
       how to handle subsequent GetXXXX(), SetXXXX(), DefinedXXXX(), RemoveXXXX(), AddXXXX()
       calls.  The basic options you can pass in are:

       type - This tells Stanza how to handle the call.  The possible values are:

                  array - The value to set and returned is an an array
                          reference.  For example, <group/> in jabber:iq:roster.

                  child - This tells Stanza that it needs to look for the
                          __netxmpp__ style namesapced children.  AddXXX() adds
                          a new child, and GetXXX() will return a new Stanza
                          object representing the packet.

                  flag - This is for child elements that are tags by themselves:
                         <foo/>.  Since the presence of the tag is what is
                         important, and there is no cdata to store, we just call
                         it a flag.

                  jid - The value is a Jabber ID.  GetXXX() will return a
                        Net::XMPP::JID object unless you pass it "jid", then it
                        returns a string.

                  master - The GetXXX() and SetXXX() calls return and take a
                           hash representing all of the GetXXX() and SetXXX()
                           calls.  For example:


                           Translates into:


                           GetTest() would return a hash containing what the
                           packet contains:

                             { foo=>"bar",  bar=>"baz" }

                  raw - This will stick whatever raw XML you specify directly
                        into the Stanza at the point where the path specifies.

                  scalar - This will set and get a scalar value.  This is the
                           main workhorse as attributes and CDATA is represented
                           by a scalar.  This is the default setting if you do
                           not provide one.

                  special - The special type is unique in that instead of a
                            string "special", you actually give it an array:

                              [ "special" , <subtype> ]

                            This allows Net::XMPP to be able to handle the
                            SetXXXX() call in a special manner according to your
                            choosing.  Right now this is mainly used by
                            jabber:iq:time to automatically set the time info in
                            the correct format, and jabber:iq:version to set the
                            machine OS and add the Net::Jabber version to the
                            return packet.  You will likely NOT need to use
                            this, but I wanted to mention it.

                  timestamp - If you call SetXXX() but do not pass it anything,
                              or pass it "", then Net::XMPP will place a
                              timestamp in the xpath location.

            path - This is the XPath path to where the bit data lives.  The
                   difference.  Now, this is not full XPath due to the nature
                   of how it gets used.  Instead of providing a rooted path
                   all the way to the top, it's a relative path ignoring what
                   the parent is.  For example, if the "tag" you specified was
                   "foo", and the path is "bar/text()", then the XPath will be
                   rooted in the XML of the <foo/> packet.  It will set and get
                   the CDATA from:


                   For a flag and a child type, just specify the child element.
                   Take a look at the code in this file for more help on what
                   this means.  Also, read up on XPath if you don't already know
                   what it is.

            child - This is a hash reference that tells Net::XMPP how to handle
                    adding and getting child objects.  The keys for the hash are
                    as follows:

                    ns - the real or custom (__netxmpp__) namesapce to use for
                         this child packet.

                    skip_xmlns => 1 - this tells Net::XMPP not to add an
                                      xmlns='' into the XML for the child

                    specify_name => 1 - allows you to call NewChild("ns","tag")
                                        and specify the tag to use for the child
                                        object.  This, IMHO, is BAD XML
                                        practice.  You should always know what
                                        the tag of the child is and use an
                                        attribute or CDATA to change the type
                                        of the stanza.  You do not want to use

                    tag - If you use specify_name, then this is the default tag
                          to use.  You do not want to use this.

            calls - Array reference telling Net::XMPP what functions to create
                    for this name.  For most of the types above you will get
                    Get, Set, Defined, and Remove.  For child types you need to
                    decide how you API will look and specify them yourself:


                   It all depends on how you want your API to look.

         Once more... The following:

           &add_ns(ns    => "mynamespace",
                   tag   => "mytag",
                   xpath => {
                             JID       => { type=>'jid', path => '@jid' },
                             Username  => { path => 'username/text()' },
                             Test      => { type => 'master' }

         generates the following API calls:


   Wrap Up
       Well.  I hope that I have not scared you off from writing a custom namespace for you
       application and use Net::XMPP.  Look in the Net::XMPP::Protocol manpage for an example on
       using the add_ns() function to register your custom namespace so that Net::XMPP can
       properly handle it.


       Originally authored by Ryan Eatmon.

       Previously maintained by Eric Hacker.

       Currently maintained by Darian Anthony Patrick.


       This module is free software, you can redistribute it and/or modify it under the LGPL 2.1.