On Thu, Jul 21, 2011 at 5:41 AM, Waqas Hussain <waqa...@gmail.com> wrote: > On Thu, Jul 21, 2011 at 2:36 AM, Dave Cridland <d...@cridland.net> 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).
Then require a version number in the XML from vendors, and then determine whether it's latest or not during the rendering :) /K
