> Is it worth giving it another chance at the MediaWiki "Hackathon" in
Berlin in May, though, assuming you're going to that? Perhaps in person
people will be less likely to just ignore the issue? It's only two
months away, so maybe it's worth waiting.
I'm going yes, but am not to positive about people having a different attitude there. In any case, the only real drawback I see to making SMW use Validator at this point, and then have it in MW core later on, is the small effort you need to avoid loading the copy SMW has when MW is already loading it. Also, unless you want a new SMW to become dependent on MW 1.18 (or whatever version Validator gets in), you'll need an included copy anyway.
> I do not quite understand how Validator groups parameters, or how it associates parameters with parser functions (does it?).
Not really, although it provides an utility class to make parser hooks that use the other Validator functionality out of the box, but there are (parser related) issues with it, so I suggest not using it for SMW.
> In our case, we have multiple parser functions (#ask, #show) that refer
to the query printers, but the expected parameters are defined by the
printers, not by the parser function.
The core validator class really does not care about the context, and just needs an associative array with the user-provided parameters and an array with your parameter definitions. See . The methods returning the parameter definitions would be the same ones that are already returning the current array-based definitions. Actual handling of the parameters (with code similar to the linked example) would happen in the base query printer class.
> On what level would something like documentation generation then happen
(as we cannot generate a single canonical documentation for #ask)?
Currently the documentation generating code (which is actually a parser hook provided by Validator) only handles parser hooks implemented via the earlier mentioned utility class. It's not clear to me how this parser hook can nicely handle everything defining parameters, as it needs to know how to access the code, and in case of SMW and Maps needs to be able to handle parameters getting added depending on the value of another parameter (format and service, respectively). In any case, the documentation generation is actually a good example of functionality made possible by having these kinds of parameter definitions which I did not think of until after writing Validator. This was when I was writing SubPageList, and started on the docs, and thought "well, this info is already in the extension, if only I could get it out" :)
Jeroen De Dauw
Don't panic. Don't be evil.