Hey James,

First of all: bravo, this is outstanding work :)

(The rest of the mail is technical, so if you're not into that, you might want to drop out here :)

> + JS implemented condition string (query string) parser

Before we create such a parser, we need to be able to represent queries in some form (else what would the parser output?). In PHP we have the SMWDescription classes for this, while in JS we have nothing yet. Having such objects is quite important for re-usability, testability and easy of understanding the code in general. I wrote a few lines on this at the end of [0].

Once we have this we can happily serialize and unserialize these objects in formats such as the ask wikitext via dedicated service objects. For dynamic result printers this is perhaps not the ideal approach though. Why would they need to construct such a serialization (which is really mean for use in wikitext pages) that the backend then just needs to parse again? Would be nicer if the API could deal with these description objects directly.

The parser and formatters for the query descriptions can be quickly implemented in JS making use of a new API module. This ensures completeness and consistency with the PHP implementation, at the cost of some latency. Later on the implementation of these can always be changed without affecting other parts of the system.

Some interfaces

* smw.AskParser: parse( string, options ) -> parserResult // containing validity, error array and if valid smw.QueryDescription
* smw.AskFormatter: format( smw.QueryDescription, options ) -> string
* smw.Store: runQuery( smw.QueryDescription, params ) -> smw.QueryResult // main implementation of this would use the ask API

> + dataValue parsing (right now srf.api.results only implements
> parseDate, getISO8601Date as this was needed for the SRF\EventCalendar
> event parsing)

We are currently working on this as part of the Wikidata project, see the DataValues section of [0]. Since SMW 1.9 will require the DataValues extension already, even though we won't switch over the value objects just yet, you can already implement such parsers, formatters and value objects in JS and make them work with current SMW. Then once we switch the PHP over, needed changes in JS should be very few and easy to make.

Please do keep an eye on the work being done here already before spending effort on creating new components. For instance, we (the Wikidata team) investigated date parsing quite extensively recently (>100 emails on the subject) and will soon implement this in a way that it will very likely be usable for SMW 1.9.

[0] http://meta.wikimedia.org/wiki/Wikidata/Notes/SMW_and_Wikidata


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