Vega-lite: Support different Vega subsets

[domoritz]

See https://www.mapd.com/blog/2017/07/22/vega-makes-visualizing-big-data-easy/

[willium]

Just to be clear, Vega doesn't support SQL, so they just extended Vega to allow it in the spec, and their engine actually does the queries right? You're proposing that we add data.sql to Vega-lite to produce Vega that will work for them, but not for anyone else (since Vega won't do anything with it, right?)

I wonder if there is a better way to allow Vega-lite to compile to some alternate Vega schema (i.e. one that allows data.sql w/ pass through) without adding support on a case-by-case basis

[jheer]

I agree with @willium's concerns. I would also note that MapD uses their own "flavor" (subset) of Vega, so adding this feature is useless if the emitted Vega doesn't match their version -- and it clearly does not. For example: limited mark types (including no groups), no expressions, no signals, etc.

Perhaps we should organize a Vega workshop where we can do things like hammer out specification definitions at varying levels of granularity. For example, what minimal subset of Vega is needed for Vega-Lite, and so on!

[domoritz]

Agreed. I changed the title and will close this for now until we have a better plan.

[willium]

I was actually a little confused reading their announcement and had to double check that Vega does not in-fact support SQL.
"Vega supports SQL statements"
"A Vega specification consist of: a data source selection, which can be SQL statements or in-line data..."
It seems like (as Jeff said) this Vega is "MapD Vega" and not "the open-source Vega specification developed by Jeffrey Heer and his group at the University of Washington."

Worried this might confuse others...