Re: [help-GIFT] MRML stuff

[Wolfgang Müller]

>  Ok, here is the mainline of my twisted thinking :-)
>  * I thought of stylesheets to convert from versions to versions.
> However, this would mean having a base version. DO we take the curent as
> base? I do not think this is wise. Rather we should "abstract" MRML
> somehow and have some way of extending this abstraction. If you think
> about it, the process of defining a stylesheet anyway forces you to do
> so...

Yes, and no. I think we are thinking of two kinds of style sheets here. You 
are thinking of creating a whole new framework where you do some kind of more 
or less dynamic binding within libMRML to operations provided by the plugins. 
BTW although this smells like JAVA, you could do this in c++, too, what you 
would have to provide as a plugin programmer, would be a hash from function 
name to function object. This is a cool idea.

What I was thinking of, was much more simple. I assume that mrml works nicely 
for this 1.0 version, and that some people have code for that written for the 
GIFT. Hmm. Strong assumption. Anyway. What I thought of would be libMRML 
providing a service like: my plugin understands "1.0", the current session is 
in "2.0" so there is a 2->1 stylesheet that makes the plugin think it gets 
(and gives back) 1, while everything else works in 2. This would basically 
mean no additional work, except including an exsisting XSLT into GIFT.

>  The way I see this is the fact of defining a meta-language, propably
> close to an enhanced Schema, allowing to define the stucture (syntax
> abnd rules) of MRML but also link to some implementation. You would end
> up with something which looks like:
>  <mrml-xsd:element name="open-session" method="openMRMLSession"
> valid-from-version="1.0"/>
>  <mrml-xsd:method name="openMRMLSession">
>    <mrml-xsd:implemented-as name="...."/>
>  </.. >

This would mean more work, but it would be simply cool. It would be 
interesting to work out, how far you can go with this interpreter pattern.

>  # the methods implemented would be reusable in the case of a MRML
> syntax change (concepts remains the same)

OK. The simpler use of stylesheets would accomplish that, too.

>  # This would enforce consistencies between version. The MRML message
> would start with a attribute (that shoudl anyweay be added). Any
> subsequent tag not "valid-from" this version onwards would be seen as an
> error.
>  # This process will make easier the handling of MRML syntax errors
> since, in the spec meta-language nothing prevents to specify exceptions.
>  # last but not least, distribute such a library would ease the job to a
> lot of people to implement MRML.

Yes, and no :-) . While I think that it would surely be helpful within 
libMRML, for attracting plugin writers I think the danger is a bit to make 
things too beautifully. I find what I have seen of JAVA DOM very beautiful, 
but I would be interested to know how many people within this list use or 
have used it to its full extent. This was the main observation leading to the 
"people get some XML tree and extract what they need"-architecture, as it is 
used in GIFT today. However, as the crowd overwhelming us with external 
plugins is not so huge, it might be time to try something different.

At the same time, with a framework that is as flexible as what you propose, 
one should surely be able to mimick the olde behaviour.

Cheers,
Wolfgang