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

Dave Cridland dave at cridland.net
Sat Oct 6 12:55:44 UTC 2012


Sounds like you should just do what you need with a private extension, then.
On Oct 4, 2012 6:21 AM, "Andreas Kuckartz" <A.Kuckartz at ping.de> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20121006/53d0b724/attachment.html>


More information about the Standards mailing list