Web services have no more in common with IRC services than with a taxi service. Web services use XML because it is a markup language formulated from the same superset as HTML, meaning they share a common syntax but allows them to separate data from presentation. They use XML to allow other websites to use their data. IRC services however have no link with HTML, SGML, or XML, they don't need to share their data across multiple arenas, they represent and work for a single IRC network, nothing more.
If you'll avert you eyes from XML for a few moments you may notice that the basic functions you're suggesting can be obtained in a much simpler and more IRC-centric way:
/*serv syntax command subcommand ... subcommandN
The command returns something in a format like: command syntax: [color:red]token 'string' (token-option|token-option|token-option) [optional-token][/color]
eg.
akick syntax: channel 'add' mask [reason]
akick syntax: channel ('del'|'stick'|'unstick') mask
akick syntax: channel ('list'|'view') [mask]
akick syntax: channel ('enforce'|'clear')
You could even go as far as to have a /*serv grammar command returning a grammar list detailing the format of the token types given in the syntax replies.
Using a system like that you've removed the need for:
- Extra connections to external files
- Segregating documentation from services
- XML parsing
- External protocols altogether
As for your 'other applications', they're really something apart from the IRCd. That is unless you expect different networks to want to automatically share that information. Of course if they did that then opers on one network would to a large extent have oper control over another, which I don't think any network admin would ever want. Whois replies are already structured.
