[Standards-JIG] Infobits again

Peter Saint-Andre stpeter at jabber.org
Fri Feb 13 22:54:23 UTC 2004

On Wed, 2004-02-11 at 13:15, Ralph Meijer wrote:
> Hi stpeter and others,
> have you been giving any though to the infobits vs. namespaces debate
> recently? I noticed my JEP went to deferred because of inactivity, and
> the cause of the inactivity is partially because of infobits.

As I blogged about last night, I'm seeing less need to develop online
user directories, which were the original impetus behind the entity
metadata spec (which morphed into infobits and related JEPs). I think
that kind of social networking application (how do I find people with
similar interests/location/etc.?) is not a core area for the Jabber
community to focus on. Rather, I think that social networking sites will
see the benefit of Jabber (if we convince them) and embed things like
presence into their offerings. So I must admit that I've become less
eager to develop this kind of thing native to Jabber.

What need do we have for a metadata format like infobits outside of user
directories or a vCard replacement? It is possible to use such a format
to define extended presence data (e.g., user activity/mood), geolocation
information, and so on. I think we need to weigh the pro's and con's of
doing this using generalized metadata formats such as Dublin Core.  Here
are some considerations:

1. We may want to specify datatypes in a way that is more strict than
Dublin Core (or whatever) does. For example, in the Tunes proposal
(JEP-0118) we would like to specify that the length of a piece of music
has datatype xs:duration, which is more strict than what Dublin Core
specifies for its Extent element. (In fact, the mere existence of
datatyping in Dublin Core is questionable to me.) Overloading the Dublin
Core Extent element seems problematic to me -- what if we overload it
with one datatype in a certain context but a different datatype in a
different context? It seems better to define our own element here and
datatype it correctly, then define some other element with a different
datatype for use in a different context (let's say, file transfer where
extent might be the number of bytes of a file). This would argue against
using any common metadata format, no matter how encoded (infobits or
namespaced elements), and instead define our own elements.

2. As to infobits (<bit key='DC.title'>King Lear</bit>) vs. namespaced
elements (<dc:title>King Lear</dc:title>) vs. Jabber-defined element
names (<title>King Lear</title>), I'm beginning to think that it doesn't
matter all that much for several reasons. One, if we need to translate
Jabber formats into some other format, we can define a mapping of Jabber
elements to the other format. There might be times when we want to
re-use a format defined by another spec (e.g., Dublin Core for metadata
or PIDF for presence), and in those circumstances we might want to
import the XML structure wholesale (e.g., see the PIDF I-D I just wrote)
or we might want to use only a few bits of data (e.g., we might do that
for extended presence data via pubsub). I don't know how common it will
be to do the latter, but I think the question is: what is easier for us
to work with, and more sustainable going forward? When we have formats
that we want to translate into another system across network boundaries
(e.g., we might do this with geolocation information), then a gateway
can do the translation. Is it easier for the gateway to receive data in
infobits, namespaced elements, or Jabber-defined elements? What's easier
for clients? So far we've used Jabber-defined elements, and don't seem
to be worse off because of that.

3. Other protocols and information formats have not necessarily defined
things very cleanly. See the datatyping discussion above. It seems
better for us in many cases to define our own formats so that we can
clearly set expectations regarding datatypes and such. But naturally it
would be good to define how to transform Jabber formats to other formats
if we think we will need that, and to do that up front.

Sorry, that was kind of rambling.


More information about the Standards mailing list