Recently I have been spending a lot of time working out what an open
EGL would consist of. In order for me to explain my thinking it is
necessary to point out a few interesting things about how EGL is
formulated. At one level it is like any other programming language. It
has a grammar for the source code and a compiler that takes that source
code to produce binaries understandable by a computer. Typically, the
concepts a programming language works with are surfaced to the
programmer through keywords that are well understood by the compiler.
EGL has its fair share of keywords to denote typical programming
concepts like type declarations, procedural statements, etc. However,
EGL also defines two related concepts called Stereotypes and
Annotations. Both a Stereotype and an Annotation type are typical EGL
type definitions whose purpose is to add extra information (metadata)
to some EGL element like a record definition or a field in a program.
This extra information is then used by the compiler to do fancy
transformations of the EGL code into some runtime system. A classic
example of this is extending a given record definition of something
like Customer with the SQLRecord stereotype:

Record Customer type SQLRecord { tablenames=[["CUSTTBL"}} }

customerNumber int { column = "CUSTNO" };

...

end

The interesting thing to note here is that SQLRecord itself is a record
definition that has been specially tagged such that it can be used as a
stereotype. However, at this time only the EGL team creates such
definitions. This would be one of the first elements to an open EGL:
Anyone can create their own Stereotype and Annotation type definitions
for general use in allowing programmers to specify simple declarative
information. Now this begs the question - how do I use this extra
information?

To understand this let me explain a little about how we use it. One of
the standard places this extra info is used is in the context of the
EGL IO statements like ADD, GET, DELETE, etc. These statements have an
abstract concept behind them that becomes concrete based on the extra
info that has been attached to the object of the statement. In the case
of a variable that has been defined as Customer with its associated SQLRecord
information the compiler then has enough information to generate the
associated SQL code implied by the combination of the abstract IO
statement semantic and the RDB table mapping defined with SQLRecord.

So again, today the EGL team is the only one that can add the extended
transformations into the compiler that are based on a given Stereotype
or Annotation. Therefore the second part of an open EGL is the ability
to extend the compiler/code generator. The correlary to this is that a
standard model of EGL from which to generate code has to exist.

Some possible usage scenarios to chew on:

• Define your own generator of EGL for a platform we do not support
• Define new stereotype LDAPRecord and provide the code generation
  extensions into an existing generator that support usage of LDAP
  records in the standard EGL IO statements.
• Integrate EGL into a Model Driven Development IDE where EGL is the
  programming language. I should note here that one possible place for an
  open EGL to land is within the Eclipse GMT (Generative Modeling Tools)
  subproject. This is because what EGL is doing is very close to what
  generating code from models does but EGL as a language lets you code
  and stay at the model level without ever dropping into the generated
  code.

So my questions to the community are:

• Is an open EGL that lets you define new types of metadata and also
  access that metadata from the open model of EGL of interest to anyone?
• What other scenarios are interesting?