> and for recording errors, i.e. we would still use SMW's error reporting mechanisms

Yes, Validator keeps track of errors, but does not display them, which is up to whatever code that's using it. (However, it does have a parser hook <listerrors /> which can be used to display all errors on a page, but this is just an utility to demonstrate what you can do when handling parameters in such a way.)

> Would you be willing to implement these basic changes in SMW and SRF?

Sure, I'll have a look at it after I finished work on Maps and Semantic Maps 0.8.

> "limit" is a parameter that is introduced and used by the query parser, not by any result printer. So it seems wrong if the result printers report this as "their" parameter.

The getParameters method in the query printers is supposed a list of parameters supported when using the query printer, which does not have to be the same as the parameters they define themselves. I don't see any harm in having the method in the base query printer class join it's stuff with the return values of a similar method in the query parser. You can of course also do this join everywhere where you obtain the parameters that belong to a query printer, but I can't think of any use case where this would be preferred over the former approach. Maybe I'm missing something though. In any case, both approaches can easily be changed into the other.

> Parameters for individual printouts are used in various places by different parts of the code. Which parameters are valid may depend on the type of printout and (if it is a printout for a property) on the datatype of the property.

Can you give a concrete example of this? I suspect I do not understand the behaviour well enough at this point to properly implement handling of it.

> It probably makes sense to assume that the user of such parameters (e.g. Special:Ask) is always aware of the general logical structure (which components govern which parameters) and only uses the facility to get a list of relevant parameters (without any "logic" attached to it).

What about adding something to the parameter definitions that indicates if they should be displayed in GUIs or not?


Jeroen De Dauw
Don't panic. Don't be evil.