[Standards] RDFa ? Re: Call for Experience: Advancement of XEP-0071 (XHTML-IM) to Final

Andreas Kuckartz A.Kuckartz at ping.de
Thu Oct 4 05:21:31 UTC 2012


The "why?" is a good question.

And I have a simple answer: It would be the most simple way to implement
my use case, because I then know that the annotate.js library can be
used (https://github.com/szabyg/annotate.js).

annotate.js demos are available here, the second one is updated ever 24
hours:
http://szabyg.github.com/annotate.js/
http://dev.iks-project.eu:8081/enhancervie

I will have a look at the implementation changes which would be implied
by using RDF/XML instead of RDFa. But I fear that it might complicate
that work to much.

Cheers,
Andreas
---

Ralph Meijer:
> While I'm sure we could alter XEP-0071 to add support for RDFa, I have
> to wonder why that is desirable.
> 
> As I see it, the main purpose of having XEP-0071 was to standardize
> existing efforts to have light *presentational* mark-up for instant
> messages. In practice, a client would mostly use a chat UI element with
> a few helper widgets for adding styles (like bold) and URLs. One
> wouldn't typically write HTML directly.
> 
> As an aside, I have personally gone as far as patching Gajim to further
> restrict the allowed elements and styles (mainly because of iChat and
> Adium).
> 
> RDFa, on the other hand, would likely be for marking up a message
> *semantically*. Standard practice in XMPP is to just add a new child
> element to the <message/> stanza for that. I.e. as a sibling of <body/>
> and (in this case) <html/>. You could simply add RDF/XML constructs,
> while keeping our restrictions on the use of XML namespace prefixes in
> mind.
> 
> For non-IM purposes, I have used embedded Atom Entry documents (as
> Publish-Subscribe payloads), using link elements for denoting triples.
> 
> I also have to note that we have traditionally shied away from using
> all-encompassing vocabularies in favor of application-specific ones.
> E.g. XEP-0080 defines its own way to record addresses and geo-location
> information, instead of using an existing gazillion page RFC. :-)
> 
> In any case, I'd welcome alternative points of view, of course.




More information about the Standards mailing list