[Standards-JIG] Infobits again

Jacek Konieczny jajcus at bnet.pl
Sat Feb 14 16:22:20 UTC 2004

On Fri, Feb 13, 2004 at 03:54:23PM -0700, Peter Saint-Andre wrote:
> 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).

Global online dictionary is one of most wanted features by
not-yet-jabber-users - those who think legacy networks are much better
because they can easyly find their friends there.

> 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.

Do not overloade other data types and formats! Use them as they are or
define out own ones.

> 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.

It does matter.

> One, if we need to translate
> Jabber formats into some other format, we can define a mapping of Jabber
> elements to the other format. 

It is hard to define sane mapping between flat key/value format (like
infobits) to really structured data.

> 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.

If all Jabber application would use real XML pasers, as they should,
then using XML, namespaces, structured data would be much easier to use
than anything else. Imagine - translating from jabber-defined element to
some other XML data format would be as easy as applying XSLT template.

Introducing dumb key/value format just because commonly used Jabber
libraries don't work well with namespaces seems like a big mistake to

> 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.

There is nothing wrong in custom Jabber datatypes, but it is always
better to use something that already exists if it fits.
Eg. RDF is very flexible and it can be easily used in Jabber. Many
jabber-specific schemas would be required, but they could be used along
all the well-known RDF schmas using the same protocol. We don't have to
use any standard RDF datatypes for describing Jabber entities, but we
can still use them for additional information about Jabber entities and
for describing other objects in Jabber.


More information about the Standards mailing list