Vega-lite: Allow spec without data source

[kanitw]

{
  "$schema": "https://vega.github.io/schema/vega-lite/v4.json",
  "layer": [
    {
      "data": {
        "values": [
          {"a": "A", "b": 28},
          {"a": "B", "b": 55},
          {"a": "C", "b": 43},
          {"a": "D", "b": 91},
          {"a": "E", "b": -81},
          {"a": "F", "b": 53},
          {"a": "G", "b": -19},
          {"a": "H", "b": 87},
          {"a": "I", "b": 52}
        ]
      },
      "mark": "line",
      "encoding": {
        "x": {"field": "a", "type": "ordinal"},
        "y": {"field": "b", "type": "quantitative"}
      }
    },
    {"mark": "rule", "encoding": {"y": {"value": 50}}}
  ]
}

should render the rule layer and the rule layer should have no data source bound in Vega.

[kanitw]

• [ ] For this reason, layer_bar_annotations.vl needs to add data: {values: [{}]}.

[domoritz]

• [ ] Same with layer_line_datum_rule.vl

[kanitw]

• [ ] As we fix this issue, we should also make the following work:

{
  "$schema": "https://vega.github.io/schema/vega-lite/v4.json",
  "data": {
        "values": [
          {"a": "A", "b": 28},
          {"a": "B", "b": 55},
          {"a": "C", "b": 43},
          {"a": "D", "b": 91},
          {"a": "E", "b": -81},
          {"a": "F", "b": 53},
          {"a": "G", "b": -19},
          {"a": "H", "b": 87},
          {"a": "I", "b": 52}
        ]
      },
  "layer": [
    {
      "mark": "line",
      "encoding": {
        "x": {"field": "a", "type": "ordinal"},
        "y": {"field": "b", "type": "quantitative"}
      }
    },
    {
      data: null,  //overriding the derived data
      "mark": "rule", "encoding": {"y": {"value": 50}}
   }
  ]
}

[marcprux]

While we are thinking about this, might we also consider having a spec without any data defined at all default to "values": [1]? That would make this very minimal spec work:

{ "mark": "circle" }

As it stands now, a novice user exploring vega-lite's grammar needs to have a fair amount of insight into the workings of the data flow.

{
  "data": { "values": [1] },
  "mark": "circle"
}

[domoritz]

What behavior do you propose for multi-view specifications?

[marcprux]

It would be the same as it is now: child layers inherit the parent data source (unless it is null'd out or redefined). So this spec would just use the root layer's (implicit) "data": { "values": [1] }:

{
  "vconcat": [
    {
        "hconcat": [
          { "mark": "circle" },
          { "mark": "tick" }
        ]
    },
    {
        "hconcat": [
          { "mark": "point" },
          { "mark": "square" }
        ]
    }
  ]
}

[domoritz]

Okay, so the implicit data is only at the root. I could see that working.

[jakevdp]

I think the empty default data is a good idea, though I'd mildly advocate for "data": { "values": [{}] } rather than "data": { "values": [1] }.

[marcprux]

[{}] works for me too. Perhaps a deserves a name, like "the unit datum" or "the identity datum"?

[domoritz]

By the way, we may not even need to fill in any data since Vega renders marks without data bindings as a single mark.

{
  "$schema": "https://vega.github.io/schema/vega/v5.json",
  "marks": [
    {
      "type": "text",
      "encode": {
        "enter": {
          "text": {"value": "Hello World"}
        }
      }
    }
  ]
}

[kanitw]

we may not even need to fill in any data

We should not fill any data. That's the original intention. Sorry for not being clear.

[eflister]

may i also propose that a mark without an encoding to a datasource also be treated in this manner (as if there is no datasource), as a way to address #7011 without having to specify a dummy datasource?

[domoritz]

I like that idea as an extension of this issue! Thanks for the suggestion @eflister.

[kanitw]

may i also propose that a mark without an encoding to a datasource also be treated in this manner (as if there is no datasource), as a way to address #7011 without having to specify a dummy datasource?

I disagree. If you specify a driving data collection for marks, there should be one mark per driving data whether you specify encoding or not.

[kanitw]

data: [{}] already works today. This issue is more like suggesting that unit spec can work without data at all.

We should perhaps allow data: null for child specs that wouldn't adopt data from its parent.