Closed mitar closed 4 years ago
Yes, this is missing. Thank you.
(And FYI the quotes are because the Media-Type in that example is JSON, and that value being set into JSON is a JSON string.)
(And FYI the quotes are because the Media-Type in that example is JSON, and that value being set into JSON is a JSON string.)
I do not think [3:5]
is a valid selector for JSON, no?
I do not think
[3:5]
is a valid selector for JSON, no?
That is valid for JSON. It presumes the value is an array or string, and selects elements 3-5 in an array or string. If the value is not an array or string, it throws an error.
That is valid for JSON. It presumes the value is an array or string, and selects elements 3-5 in an array or string. If the value is not an array or string, it throws an error.
So if those selectors really depend so much on content type, I think all examples should provide that context. Otherwise this is really hard to understand.
It depends not on the Content-Type, but on the Parser specification.
It sounds like we should add some language saying "The Parser is responsible for defining the format of the left-hand-side and right-hand-side in a braid patch."
Yes, you are right. But I think we then have to standardize few of those standard parsers?
Yes, we need specifications for parsers and mergers.
Opened #14 for clarifying the parsers.
I think you should formally specify the grammars for what you are defining there. Both for the patch specification and for patch itself. Like:
What of this is structure, what are values. Where are spaces allowed? Are there comments? How many elements should be there in the parameters? Can
sync9
get additional arguments? What are possible values for the first?bytes
? Is this a reserved word? Is there a new registry your spec is introducing of those words? Who will maintain that registry, IANA?Similarly, you have example:
Why are quotes there? Where do they come from? What are quoting rules there?