[Standards-JIG] Infobits again

Peter Saint-Andre stpeter at jabber.org
Tue Feb 17 23:40:17 UTC 2004


On Sat, 2004-02-14 at 09:22, Jacek Konieczny wrote:
> 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.

Yes, but does that need to happen in-band?

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

I'm agreeing with you.

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

Please justify that statement. It's not obvious to me that RDF is easy
to use, or can be easily used in Jabber. For one, it would require the
relevant applications to embed an RDF parser (RDF!=XML).

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

I looked long and hard at RDF and decided that it would not work for us.
If you have evidence that RDF would work well in the Jabber world, I'd
love to see it.

Peter





More information about the Standards mailing list