Re: [gdome]MathML DOM implementation: I need some advise

[Luca Padovani <lpadovan cs unibo it>]

Hi,

On Thu, 2003-10-02 at 15:11, Pierre-Paul Delisle wrote:
> This is the reason pushing me for the C implementation.
> Later we will have just to update gmetadom (or to create a gmetammldom...)

right

> >Have you considered automatic generation
> >of the code? A fair amount of methods can be generated automatically I
> >think, this would reduce the code to hand-write and would make it easier
> >to switch to an alternative approach if the one you try first does not
> >seem to work well.
> I was going to start with "copy and paste" from the Gdome code itself and 
> from the MathML2 specification. Can you suggest me a tool to help me 
> automatically generate most of the code?

as I said you should be able to implement it without knowing Gdome2
internals if we assume for instance that upcasting from a MathML element
to a DOM element is done via an explicit method call and not simply a C
cast. This is quite reasonable after all since C has no knowledge of
what upcasting really is...

For the automatic generation, most of the IDL attributes in MathML DOM
interfaces correspond to XML attributes, so all the code to get/set
their value can be generated. Also, the list of parameters, the
correspondence of IDL types with C types, the extra methods provided by
every implementation (such as the up/down casts, constructors and
similar others), can be generated with great benefit for future
maintenance.

In gmetadom we're doing this for generating the bindings directly from
the XML encoding of the W3C spec for DOM. I assume the MathML spec also
has a similar XML encoding. From there, it is quite easy to write XSLT
stylesheets that generate real code. You can have a look at gmetadom
sources for examples of such stylesheets. In your case however, you
wouldn't be able to generate ALL the code: at most you'll be able to
generate prototypes and methods with an empty body to be filled by hand.
Or, you can provide the method bodies and any other missing information
in a separate set of XML files and combine them with the XML files for
MathML DOM. You can see an example of this technique in gmetadom again
(Ocaml binding), where we keep a parallel set of XML files to know which
arguments can be "nullable", that is which parameters can accept a NULL
value. This is an example of missing information that cannot be inferred
safely from the spec.

If you're interested in going this way feel free to ask for more
information.

Cheers,
-- luca