Pragmatism is definitely needed when working with XML. It looks simple, but actually the full rules are a nightmare, so trying to write code on day 1 that fulfills all the rules is a lost cause. E.g. how many remember that the name of an attribute cannot start with the letters "xml" in any combination of cases, but it can start with a colon?

 

Best regards,

 

Matt

 

While we can work around that, adding "localName" opens up a large number of other new commands that would then be needed, e.g. to find the datatype of the property type to know whether to recurse again with do :() over a contained object or collection; to find the supertype of the current type; to find the kind of List widget a property type uses and its legal values etc. Essentially, MERL is a language for navigating models, and doesn't have commands to navigate metamodels. Adding those commands would increase the size of MERL by at least 50% - and the topic next to yours in the forum shows that some people already need to take a big breath before getting started.

 

Of course, we recognise the desire to write meta-programs in MERL, and indeed we use that freely in some areas (e.g. subreport '_' type run). While there is a little duplication involved in writing local names explicitly in generators, as well as in the metamodel, that's only for one person - the metamodeler - and not for all the modelers. Unless you have hundreds of types with dozens of properties each, that shouldn't be too bad.

 

BTW Maybe one solution for you, if all you need is uniqueness of attribute names, would be to add a number to the end of the name:

 

$ix='0'

do :() { ... type%var $++ix ...}

If you've read the manuals and walked through the examples, getting your hands dirty is probably the best way to proceed. Do a quick recap of 5.3.1 Getting started with MERL, and dive in to some relatively simple part of what you need to generate, e.g. the top-level structure.

 

Once you have more than a few dozen lines of MERL, you'll want to think about how best to structure your generators. A page of brief advice is in 5.1.2 Building non-trivial generators. The DSM book would also be useful, with over 70 pages on generators covering theory, practice, and in-depth examples.

 

Of course, feel free to post here if you get stuck!

 

I'm definitely a noob when it  comes to domain specific modeling and languages. I'm currently designing a DSML for designing simple programs for an educational concurrent virtual machine (very limited capabilities so not a lot of features to the language) and I'm now at the stage where I need to create the code generators.

 

I've read the documentation on MERL and am looking for more, if there is any. I'll start hammering away at it, but I'm hoping there are some more explanations/tutorials in addition to the online manuals.

 

Thanks and best regards,

 

Mathew Pierce