On Thu, Jul 21, 2011 at 2:36 AM, Dave Cridland <[email protected]> wrote: > On Tue Jul 19 17:03:00 2011, Peter Saint-Andre wrote: >> >> On Tue, Jul 19, 2011 at 09:00:36AM +0100, Dave Cridland wrote: >> > My plan would be that implementers would host an XML description of >> > their compliance levels, which the XSF's software listings would >> > consume and render into the software list. This would mean that most >> > changes (latest version, Core/Advanced, XEPs) would be >> > implementer-driven. >> > >> > If there is interest, I'll sketch this out in more detail. >> >> Sounds intriguing. > > So the idea is that instead of saying to the XSF, "Hey, we're Isode, and we > do this server called M-Link", we'd say "Hey, we're Isode, and we have an > implementation description at http://www.isode.com/mlink.xml";. > > Now, mlink.xml would say something like: > > <implementation xmlns='urn:xmpp:implementation-description' type='server'> > <implementer url='http://www.isode.com/'>Isode Ltd</implementer> > <fullname url='http://www.isode.com/products/m-link.html'>Isode > M-Link</fullname> > <version>R15.0v1</version> > <xep num='220'/> > <xep num='198'/> > <xep num='45'/> > <xep num='163'/> > <xep num='60'/> > <!-- [... and so on ...] --> > </implementation> > > So the XSF gathers together all these in a magical way - such as having a > file somewhere which says: > > <software-list> > <xi:include href='http://www.isode.com/mlink.xml'/> > </software-list> > > And then runs an XSLT over that periodically which spits out the HTML page, > where this stuff is rendered. Now we can have that XSLT check to see what > compliance levels are hit automatically, and add them in. > > Also added in would be a disclaimer to state that all information was > provided by the developers and the XSF takes no position on its reliability > - which is mechanically true. > > Dave.
This is a nice idea. It has been discussed before, and attempts made. One similar though not equivalent project was by Kim Alvefur (https://github.com/Zash/XMPP-Features/tree/yaml), and vendors providing the data in an XML file was discussed in the Prosody room. There's just one problem: This requires that vendors provide sane data. As one example jabberd2 has XEP-0198 support listed on their home page: http://codex.xiaoka.com/wiki/jabberd2:start (the link on the page has been changed to an older version of the spec, which is better). That said, I suppose I'm being too pessimistic. The idea is good enough to deserve an implementation. -- Waqas Hussain
