Uncombined literals

[petervaro]

Right now the specification allows the following:

{
  "type"     : "PRTDocument",
  "dialect"  : "pop-draft",
  "version"  : "2.0",
  "elements" :
  [
    "chunk 1 ",
    "chunk 2 ",
    "chunk 3"
  ]
}

which is essentially the same thing as:

{
  "type"     : "PRTDocument",
  "dialect"  : "pop-draft",
  "version"  : "2.0",
  "elements" : "chunk 1 chunk 2 chunk 3"
}

This ambiguity can lead to faulty behaviours in converters/validators. And since these two are equalent, yet one of them is containing some extra data (the split positions), the converters/validators can't reliably produce the same output.

Suggestion: The specification should be strict about this, and should not allow a string literal to be followed by another one, that is, the next one should be an HTML-like element.

Note: This new behaviour should be in either v2.1 or v3.0!

[petervaro]

One can look at this problem from a tooling-perspective as well: the specification should remain the same as it is now, but the tools should add some sanitisation before/during the validation/conversion. Which unfortunately means, it needs a secondary temporary representation, the sanitised one, which is not ideal from the speed/memory-size point of view.