[standards-jig] Infobits versus namespaced elements

Ralph Meijer jabber.org at ralphm.ik.nu
Tue Dec 23 12:22:54 UTC 2003

Hi all,

I have been awfully busy doing more important stuff (read: finishing my
thesis), and as such didn't pick up on stpeter's infobits 'revolution' so

In short, I don't think infobits are they way to go. Now for more detail:

As I understand it, stpeter attempts to define a namespace where common
used bits of information transmitted and stored in the jabber universe
can be defined. A snippet of information like infobits describes is like this
(taken from version 0.5 of the location JEP 0080):

  <loc xmlns='http://jabber.org/protocol/geoloc'>
    <info xmlns='http://jabber.org/protocol/infobits'>
      <bit key='lat'>45.44</bit>
	  <bit key='lon'>12.33</bit>
	  <bit key='DC.description'>Venice</bit>

As we can see, there is the location namespace http://.../geoloc, and
the infobits namespace. All bits have a key with a name that specifies what
the value of the bit should represent.

Version 0.3  of the location JEP had this snippet (0.4 had JEP-0112 stuff
merged in, more on that in another thread):

  <loc xmlns='http://jabber.org/protocol/geoloc'>

As you can see, we have the location namespace again, and element names
that specify what is in the element.

So, in infobits, each piece of information is identified by a key. This key
is a simple identifier, possibly with dots in it:

In XML a piece of
information is identified by the namespace and the elementname, frequently
a curly braces notation is used for this with the URI of the namespace
in the curly braces, immediately followed by the element name. This notation
is used in many XPath aware processors of XML.


JEP-0120, which defines Infobits, has a nice introduction on the why of
having a key/value structure instead of namespaced XML elements:

  The format defined herein uses a simple "key-value" structure. Although this
  may seem contrary to the XML basis of Jabber technologies, there are several
  good reasons for following this approach.  First, not all metadata formats
  that the Jabber community may want to use exist in stable XML
  representations (e.g., this is true of the vCard format).  Second, some
  metadata formats (e.g., Friend of a Friend (FOAF)) exist only in Resource
  Description Framework, whose syntax is represented in XML but whose
  semantics impose a more complex structure that requires a specialized
  (non-XML) parser.  As long as a clear mapping can be defined between such
  metadata formats and Jabber infobits, there are many benefits to developing
  a consistent, extensible metadata syntax for use in Jabber applications.

I don't see how the first and the second claim are solved using infobits.

The most important argument for using infobits seems to be the mapping. My
claim is that it is just as easy (or difficult) to map 'lat' to something
outside Jabber, as it is to map '{http://jabber.org/protocol/geoloc}lat'.

If I want to describe a chair, I first have to know what kind of chair
we are talking about. If I was to use infobits I could use the key 'chair'
for my information, but that doesn't tell me anything. I could mean the
chair person of an organisational body, or the furniture piece. We could
change the name of the key to 'org.chair' or 'furniture.chair'. Maybe
even: '{http://example.com/furniture}chair'. See my point? See also [1].

Also, the example uses DC.description to kind of refer to the Dublin
Core, without using their syntax. what if I did this:

  <loc xmlns='http://jabber.org/protocol/geoloc'>
	<description xmlns='http://purl.org/dc/elements/1.1/'>Venice</description>

or even:

  <loc xmlns='http://jabber.org/protocol/geoloc' xmlns:dc='http://purl.org/dc/elements/1.1/'>

Another disadvantage of these 'simpler' keys is that you have to centrally
register all possible keys. Maybe you can define a 'x-' prefix, but I think
that is really a hack. Using XML namespaces makes it far easier to come
up with your own data containers. Remember that this is why Jabber
is so extensible!

Depending on how much mixed data you have, infobits might use less bandwidth
than fully namespaced elements. On the other hand, both compress pretty

B.t.w. I see many element names in several protocols use short names. Why?
That is just like short names in code: harder to read. I'd rather have
'location' over 'loc', since 'locomotive' can also be shortened to 'loc'.

Let the discussion begin!

[1] http://www.xml.com/pub/a/2001/07/05/namespaces.html



More information about the Standards mailing list