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.
