I compiled this into a TraphicControlModel.mx image and inserted it into the Repository.
To create a model instance I used the following:

This works to insert the MGraph into the existing model defined in the MSchema snippet. I compiled it into an TraphicControlInstance.mx image and ran mx.exe on it with a reference to the previousTraphicControlModel.mx file.
Next, I created a DSL using MGrammar and want to produce output in an M file that represents approximately the same model instance. My first attempt was this:

That together with a DSL example of:

gives the following output in the MGrammar Preview Mode window:

Seems like it is nearly there, but I am having trouble getting the "light1" label for the TraphicLight instance referenced in the TraphicLight association of each Lamp, something like

The label of the TraphicLight instance does not matter to me (or MGrammar I assume).
When I compile the grammar into an mgx image and run mgx.exe on the sample file it creates an MGraph file alright, but not one that can be compiled and inserted into the Repository just yet.

So, my questions are these:

• Am I on the right track here?How does one create a MGraph.m file that I can compile (m.exe with a reference to the mx of the compiled MSchema) and insert into the Repository (mx.exe) without having to change anything after running the DSL sample through my mgx file of the grammar?
• How to solve the referencing of previous defined entities?
• Are there other ways to work with previously defined entities? I believe that you can also take the .Lamps of the MGraph instance of the TraphicLight instance and put them at the "root" level of the MGraph tree. But does this fit well with the MGrammar parsing?
• When does one need to resort to DynamicParser et al. to do the work?

Any input is appreciated. Thanks.
Alex

(Edited a little to clarify some more)

Alex,

Here's a sample grammar that should work with your text file and produce MGraph that conforms to the modified schema I posted above:

To answer your questions point-by-point:

Q: Am I on the right track here? How does one create a MGraph .m file that I can compile (m.exe with a reference to the mx of the compiled MSchema) and insert into the Repository (mx.exe) without having to change anything after running the DSL sample through my mgx file of the grammar?
A:At this point, you need to have the parent contain the child collection in the schema (rather than having the child reference the parent in the schema).
Q: How to solve the referencing of previous defined entities?
A:As far as I know, the parent/child approach I've shown is the only way to reference one entity from another via MGrammar. This reference is an implicit reference by containment (the parent contains the child and thereby is linked to/references the child). Creating lables in MGrammar is supported but using lables to reference another entity is currently not supported in MGrammar.
Q: Are there other ways to work with previously defined entities?
A: I believe that you can also take the .Lamps of the MGraph instance of the TraphicLight instance and put them at the "root" level of the MGraph tree. But does this fit well with the MGrammar parsing? As far as I know, this "parent contains children" approach is the only way to reference any other entities in MGrammar.
Q: When does one need to resort to DynamicParser et al. to do the work?
A:If you don't want to modify your MGrammar or your MSchema to make them play well together, you'd need to use DynamicParser or some other technique. One other technique would be to create two different schemas: an "import" schema that plays well with the grammar and can accept its output directly, and another "real" schema that is structured the way you prefer. You'd need some kind of tool to move from the one schema to the other, and that's probably where DynamicParser could come in. I've even tried using SQL scripts to move data from an import schema to a real schema; that works, but it is a bit tedious.

I realize that this process is a bit cumbersome right now, and it is not well-documented. I'll file a bug internally to get better documentation on the MGrammar/MSchema integration, and we are working hard to make the two integrate better in the future.

David

Yes, you are correct about the options at the moment. I would tend to take the latter approach as well.

I don't really know how the integration will look at this point; it's still in development. If I get more information, I'll post it here.

David

I got the following answer from Don Box:
“Our goal is to remove the distinctions between the function bodies in today’s MSchema and the right-hand-sides of grammar rules in today’s MGrammar. This includes a consistent set of operators and functions for use in both contexts as well as the ability to type-ascribe (a la today’s MSchema) the results. The corresponding design and implementation work is ongoing.�/span>

David

Alex,

Here's a sample grammar that should work with your text file and produce MGraph that conforms to the modified schema I posted above:

To answer your questions point-by-point:

Q: Am I on the right track here? How does one create a MGraph .m file that I can compile (m.exe with a reference to the mx of the compiled MSchema) and insert into the Repository (mx.exe) without having to change anything after running the DSL sample through my mgx file of the grammar?
A:At this point, you need to have the parent contain the child collection in the schema (rather than having the child reference the parent in the schema).
Q: How to solve the referencing of previous defined entities?
A:As far as I know, the parent/child approach I've shown is the only way to reference one entity from another via MGrammar. This reference is an implicit reference by containment (the parent contains the child and thereby is linked to/references the child). Creating lables in MGrammar is supported but using lables to reference another entity is currently not supported in MGrammar.
Q: Are there other ways to work with previously defined entities?
A: I believe that you can also take the .Lamps of the MGraph instance of the TraphicLight instance and put them at the "root" level of the MGraph tree. But does this fit well with the MGrammar parsing? As far as I know, this "parent contains children" approach is the only way to reference any other entities in MGrammar.
Q: When does one need to resort to DynamicParser et al. to do the work?
A:If you don't want to modify your MGrammar or your MSchema to make them play well together, you'd need to use DynamicParser or some other technique. One other technique would be to create two different schemas: an "import" schema that plays well with the grammar and can accept its output directly, and another "real" schema that is structured the way you prefer. You'd need some kind of tool to move from the one schema to the other, and that's probably where DynamicParser could come in. I've even tried using SQL scripts to move data from an import schema to a real schema; that works, but it is a bit tedious.

I realize that this process is a bit cumbersome right now, and it is not well-documented. I'll file a bug internally to get better documentation on the MGrammar/MSchema integration, and we are working hard to make the two integrate better in the future.

David

Yes, you are correct about the options at the moment. I would tend to take the latter approach as well.

I don't really know how the integration will look at this point; it's still in development. If I get more information, I'll post it here.

David

I got the following answer from Don Box:
“Our goal is to remove the distinctions between the function bodies in today’s MSchema and the right-hand-sides of grammar rules in today’s MGrammar. This includes a consistent set of operators and functions for use in both contexts as well as the ability to type-ascribe (a la today’s MSchema) the results. The corresponding design and implementation work is ongoing.�/span>

David

Yes, type-ascription and/or conversion functions would be very useful for this. I am very curious to see how this will manifest itself in the language(s).