-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSON: Encoding inner beams #299
Comments
It doesn't fit totally right to me. Is "inner" the right word for this? Looking at a slightly more complex example w/ 32nd notes: https://w3c.github.io/mnx/docs/mnx-reference/examples/beams-secondary-beam-breaks/ it seems to me that the right word for "inner" is in fact
I suppose one rationale for "inner" is that alphabetically it comes after "events" which is something we should be thinking about a bit. I'm just realizing that with "beams" coming alphabetically before "contents" parsers will have to hold on to "beams" until their content events are already defined. I can't have my "beams" parser apply beams to notes on parse since the notes won't be defined yet. One little error here and in the example. The last "events" should refer to
maybe it's:
So that a hook is an inner beam on one note that specifies its "hook" properties. (It makes more sense to me that a hook is a specialized 16th beam, not an attribute on the 8th beam. |
When migrating to JSON, I needed to find a way to encode nested beams. Here's what I came up with:
This is taken from the Beams example document.
I think this is OK, but the approach is different enough from the XML approach that I wanted to bring it up for discussion. In the XML version, we relied on nesting XML elements implicitly, so there was no concept of an explicit
"inner"
.The text was updated successfully, but these errors were encountered: